Re: [Xen-devel] [PATCH, resend] replacement for noirqdebug hack

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 02.06.06 12:32 >>>
>
>On 2 Jun 2006, at 11:02, Jan Beulich wrote:
>
>> Instead of re-establishing the noirqdebug hack earlier present in the 
>> i386 Linux code, communicate the information about
>> whether a particular IRQ is shared across domains from hypervisor to 
>> kernel.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>This is gross for a few reasons. Firstly it adds Xen cruft to a file we 
>don't currently modify, and the changes would never be mergable 
>upstream. Plus I'd prefer a lighter weight solution for handling this 
>x86 crufty corner case -- adding extra bitmaps to shared_info and 
>updating bits on every IRQ delivery is overkill imo.

I don't think this has less chances of merging than other changes to 
pre-existing files. Besides that, I don't think
sharing of IRQs across domains is an x86-only issue. And where do you see 
overkill in updating a single bit?

>What I would suggest is change note_interrupt() to only increment 
>irqs_unhandled if some new function spurious_irqs_ok(irq) returns 
>false. We can then define that function as Xen-specific and extend 
>physdev_irq_status_query to be able to determine if an irq is shared 
>across guests. We can avoid frequent hypercalls by caching the shared 
>status the first time it evaluates true (so sharedness is sticky; I'd 
>assume we would rarely take the path that executes the hypercall if the 
>irq is really not shared).

That stickiness is clearly undesirable to me - if you bring up a domU for 
testing or other temporary purposes that
makes use of an interrupt already in use elsewhere, all other users of the 
interrupt will from there on not do proper
accounting anymore. Further, how would you want to prevent doing the hypercall 
if by default interrupts are non-shared
(I hope you didn't have other intentions) and hence the (sticky) flag wasn't 
set, yet.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel