From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: APIC rework Date: Tue, 24 Nov 2009 11:25:41 -0800 Message-ID: <4B0C3335.4090302@goop.org> References: <706158FABBBA044BAD4FE898A02E4BC201CD3207E0@pdsmsx503.ccr.corp.intel.com> <706158FABBBA044BAD4FE898A02E4BC201CD3A074E@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC201CD3A074E@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 , "Jiang, Yunhong" List-Id: xen-devel@lists.xenproject.org On 11/24/09 02:04, Zhang, Xiantao wrote: >> Shoehorning trig/pol information into it as well is kind of nasty. >> And I think on any PC system it should suffice to assume GSI 0-15 are >> ISA edge-triggered active-high, GSI 16+ are PCI level-triggered >> active-low, and any exceptions are parsed out of MADT or MPBIOS. We >> pretty much have all that code, it just might need plumbing back in a >> little bit. Yunhong points out that ACPI DSDT can have overriding >> objects in the _PRT, but I don't know it ever actually gets used on >> real-world PC systems. So I would try without, but if we do end up >> needing to get this info from dom0, I think it should be via a new >> physdev_op. >> > At least dom0 parses this info from DSDT, so we can't have the assuption whether it is used or not, I think. Could you clarify this? Are you saying that Xen can't use the DSDT because dom0 does? > And I also agree to add a new physdev_op to handle this case, and it should be better way to go. > Based on this idea, I worked out the patch, attached! In this patch, we introduced a new physdev_op PHYSDEVOP_setup_gsi for each GSI setup, and each domain can require to map each GSI in this case. > In addition, I believe it is very safe to port the hypervisor patch to xen-3.4-x tree and keeps pv_ops dom0 running on it, since no logic is changed. BTW, I also tested apic and non-apic cases, they works fine after applying the patches. Could you resend the Linux patch as a delta against your previous patch? It makes it easier both to see how things are evolving, and also so I can reuse previous merges. What branch/version is your diff against? Do we still need the dummy APIC mappings? Can anything end up touching them? Thanks, J