Re: Using handle_fasteoi_irq for pirqs

["Jan Beulich" <JBeulich@novell.com>]

 >>> On 07.09.10 at 03:53, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> On 09/06/2010 05:58 PM, Jan Beulich wrote:
>>  >>> On 03.09.10 at 20:46, Jeremy Fitzhardinge <jeremy@goop.org> 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) http://gitorious.org/opensuse/kernel-source/trees/master.

>>> (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
http://xenbits.xensource.com/xen-unstable.hg?rev/c820bf73a914.

Also, regarding your earlier question on .disable - I just ran across
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/51b2b0d0921c,
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)

Jan