From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH 30 of 38] xen: implement io_apic_ops Date: Thu, 20 Nov 2008 20:27:21 -0800 Message-ID: References: <20081120093506.GB6885@elte.hu> <492597B9.8070506@goop.org> <4925D762.6040406@goop.org> <49260BE7.1080909@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <49260BE7.1080909@goop.org> (Jeremy Fitzhardinge's message of "Thu, 20 Nov 2008 17:16:23 -0800") Sender: linux-kernel-owner@vger.kernel.org To: Jeremy Fitzhardinge Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Xen-devel , the arch/x86 maintainers , Ian Campbell , Thomas Gleixner , "H. Peter Anvin" , Yinghai Lu List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge writes: > > Yes, I suppose we can statically partition the irq space. In fact the original > 2.6.18-xen dom0 kernel does precisely that, but runs into limitations because of > the compile-time limit on NR_IRQS in that kernel. If we move to a purely > dynamically allocated irq space, then having a sparse allocation if irqs becomes > reasonable again, for msis and vectorless Xen interrupts. > >> The difference is that the xen sources are not delivered using vectors. The cpu >> vector numbers we do hide and treat as an implementation detail. And I am totally >> happy not going through the vector allocation path. >> > > Right. And in the physical irq event channel case, the vector space is managed > by Xen, so we need to use Xen to allocate the vector, then program that into the > appropriate place in the ioapic. We should be able to share code with iommu for irqs handling, at first glance you are describing a pretty similar problem. Now I don't know think the interrupt remapping code is any kind of beauty but that seems to be roughly what you are doing with Xen domU. I certainly think with some careful factoring we can share the ioapic munging code. And the code to pick how we program the ioapics. >> My gut feel says that you just want to use a different set of irq operations when >> doing Xen native and working with hardware interrupts. I haven't seen the code so >> I don't know how you interact there. Except in dom0 this is not a consideration so >> I don't how it is handled. >> > > Yeah. In the domU case, where there's no physical interrupts, the Xen code > completely avoids the ioapic/vector stuff, and directly converts an event > channel into an irq. Indeed, physical irq delivery is handled the same way; its > just that the setup requires touching the ioapics to program the appropriate > vector and bind it to an event channel. Reasonable. A lot like the intel interrupt remapping code in that respect. The message we program in has little to do with the vector the interrupt arrives on. So I don't quite know where to hook it but if we are careful we should be able to get a good interrupt mapping. Eric