From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: APIC rework Date: Tue, 17 Nov 2009 10:51:23 -0800 Message-ID: <4B02F0AB.8080103@goop.org> References: <706158FABBBA044BAD4FE898A02E4BC201CD3205FF@pdsmsx503.ccr.corp.intel.com> <706158FABBBA044BAD4FE898A02E4BC201CD32062E@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC201CD32062E@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: Xen-devel , "Han, Weidong" , Keir Fraser , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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 progra= mming ioapic entries, but it depends on using ioapic logic in dom0. And i= f 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 fr= om 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 t= hrough this hypercall, and I think we also can leverage the interface MA= P_PIRQ_TYPE _GSI to build the mapping for GSI irq. Further analysis showe= s 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 betwee= n its pirq and irq. One different thing for GSI irq is that more info sho= uld 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 t= he change, I am happy to add it.=20 > =20 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.= But also consider the question whether Xen needs to get triggering info from dom0 at all, or whether it can correctly derive that info from its own parsing of the relevant tables. J