From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Using handle_fasteoi_irq for pirqs Date: Tue, 07 Sep 2010 07:58:57 +0100 Message-ID: <4C85FED10200007800014A0C@vpn.id2.novell.com> References: <4C743B2C.8070208@goop.org> <4C74E7C802000078000120C0@vpn.id2.novell.com> <4C814278.5070904@goop.org> <4C84BB580200007800014717@vpn.id2.novell.com> <4C859B27.6000400@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C859B27.6000400@goop.org> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Konrad Rzeszutek Wilk , "Xen-devel@lists.xensource.com" , Tom Kopec , Daniel Stodden List-Id: xen-devel@lists.xenproject.org >>> On 07.09.10 at 03:53, Jeremy Fitzhardinge wrote: > On 09/06/2010 05:58 PM, Jan Beulich wrote: >> >>> On 03.09.10 at 20:46, Jeremy Fitzhardinge 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/maste= r/ or (un-expanded tree of patches) http://gitorious.org/opensuse/kernel-sourc= e/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. >=20 > 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