From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: APIC rework Date: Wed, 18 Nov 2009 09:37:00 +0000 Message-ID: References: <706158FABBBA044BAD4FE898A02E4BC201CD3207E0@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC201CD3207E0@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" , Jeremy Fitzhardinge Cc: Xen-devel , "Han, Weidong" , "Jiang, Yunhong" List-Id: xen-devel@lists.xenproject.org On 18/11/2009 03:25, "Zhang, Xiantao" wrote: >> For modern dom0 don't we already assume that dom0 pirq == irq == gsi >> (see comments in ioapic_guest_write)? Perhaps we should just have that >> relationship set up by default: I think only NetBSD dom0 has >> different, and it will establish different relationship via legacy >> method of PHYSDEVOP_alloc_irq_vector and paravirtualised IOAPIC >> writes? > > The assumption should be right for dom0 today, but it still needs to register > this info to dom0's private data(d->arch.{pirq_irq, irq_pirq). > And I think maybe we should clean up the logic and let hypervisor knows the > assumption, when consulting this relationship. Well, it strikes me that existing MAP_PIRQ_TYPE_GSI fills this role already, as it is, doesn't it? Seems to me that is its whole purpose. :-) 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. -- Keir