From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Re: APIC rework Date: Wed, 18 Nov 2009 09:29:28 -0500 Message-ID: <20091118142928.GC15585@phenom.dumpdata.com> References: <706158FABBBA044BAD4FE898A02E4BC201CD3205FF@pdsmsx503.ccr.corp.intel.com> <706158FABBBA044BAD4FE898A02E4BC201CD32062E@pdsmsx503.ccr.corp.intel.com> <4B02F0AB.8080103@goop.org> <706158FABBBA044BAD4FE898A02E4BC201CD3207FB@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC201CD3207FB@pdsmsx503.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Zhang, Xiantao" Cc: Jeremy Fitzhardinge , Xen-devel , "Han, Weidong" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Wed, Nov 18, 2009 at 11:37:51AM +0800, Zhang, Xiantao wrote: > Jeremy Fitzhardinge wrote: > > On 11/17/09 06:17, Zhang, Xiantao wrote: > >> Originally, this patch is target to get rid of ioapic changes in > >> dom0. Before this patch, GSI irq should be mapped and setup through > >> dom0 programming ioapic entries, but it depends on using ioapic > >> logic in dom0. And if we remove ioapic logic from dom0, we need to > >> find new way how to setup GSI irq. And this patch comes out under > >> this situation. The idea is from that in Xen the interface > >> MAP_PIRQ_TYPE_MSI is used to build the pirq and irq mapping for MSI > >> IRQ for each domain. Since MSI IRQ can be setup through this > >> hypercall, and I think we also can leverage the interface > >> MAP_PIRQ_TYPE _GSI to build the mapping for GSI irq. Further > >> analysis showes that this interface is only used for assigning > >> devices to HVM domain in qemu, and I think it should be Okay for > >> dom0 building the mapping between its pirq and irq. One different > >> thing for GSI irq is that more info should be provided in the call, > >> since GSI IRQ has different trigger-mode and polarity (originally it > >> is provided by ioapic write in dom0). Certainly, I also think we > >> need to document the related info, and if you agree to the change, I > >> am happy to add it. > >> > > > > I don't think there's any need to overload the existing interface > > though. If we're adding new functionality then we can add a new > > interface for it (but with luck we can reuse most of the existing code > > to implement it). > > > If you're already considering a "treat this differently" flag in the > > argument, then that's a strong pointer that a new interface is > > warranted. > > Agree, and I also don't object to add a similar interface. > Since this existing interface is only used for hvm domain before, and just want to re-use it for dom. I am pretty sure it is used for PV domains too. Look in 'xen_create_msi_irq', which extracts the domain that has a PCI device for pass-through and on behalf of that domain makes the MAP_PIRQ_TYPE_MSI call. Furthermore, it is also used by Dom0 for MSI devices. What do you mean by 're-use it for dom'?