This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: Using handle_fasteoi_irq for pirqs

 >>> On 07.09.10 at 03:53, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 09/06/2010 05:58 PM, Jan Beulich wrote:
>>  >>> On 03.09.10 at 20:46, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> Where's the source to your kernel?  The one I looked at most recently
> was using handle_level_irq for everything.

Indeed, I did the switch in the master (and SLE11 SP1) kernels only
relatively recently (and only the master one is already visible to the
outside) - look at either ftp://ftp.suse.com/pub/projects/kernel/kotd/master/
or (un-expanded tree of patches) 

>>> (I just implemented PHYSDEVOP_pirq_eoi_gmfn method of getting the pirq
>>> eoi flags, but I haven't tested it yet.  I'm also not really sure what
>>> the advantage of it is.)
>> This is for you to avoid the EOI hypercall if it would be a no-op in
>> Xen anyway.
> Yes, but there's also PHYSDEVOP_irq_status_query call.  Does the "needs
> EOI" actually change from moment to moment in a way where having a
> shared page makes sense?

No, it doesn't - using this function you can of course maintain the
bitmap on your own (which we also fall back to if PHYSDEVOP_pirq_eoi_gmfn
is not supported by the hypervisor). The actual advantage of using
PHYSDEVOP_pirq_eoi_gmfn is that it implies an unmask of the
corresponding event channel - see

Also, regarding your earlier question on .disable - I just ran across
which makes me think that .enable indeed should remain an alias of
.startup, but I also think that .disable should nevertheless do the
masking (i.e. be an alias of .mask)


Xen-devel mailing list