From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Lively Subject: HVM PIC/APIC confusion in ACPI firmware? Date: Tue, 26 Sep 2006 14:20:08 -0400 Message-ID: <45196F58.4070307@virtualiron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hi Folks - I'm pretty new to ACPI (don't know my ASL from a hole in the ground :-), but I think the _PRT method has the PIC/APIC cases reversed. I'm looking at tools/firmware/acpi/acpi_dsdt.asl. The ACPI spec says a _PIC method (if defined) will be called with an argument of 1 if the host is using APIC interrupts. If the host is using PIC interrupts instead, it will either not call the _PIC method, or will call it with an argument of 0. The current _PIC method simply stores its argument into the PICD variable: Name(PICD, 0) Method(_PIC, 1) { Store(Arg0, PICD) } So PICD will contain 0 for PIC mode, and 1 for APIC mode. The _PRT method then returns a PCI routing table appropriate for the current interrupt mode: Method(_PRT, 0) { If (PICD) { Return(PRTA) } Return (PRTP) } But PRTA is a simple routing table, dealing only with PCI INTA, while PRTP is a more complex one dealing with PCI INTs A-D. It looks to me like the _PRT method is backwards, and should be returning PRTA when PICD is zero, and PRTP otherwise. Right? Dave P.S. I made this change locally, but haven't seen much of a difference so far. It seems to work as well as the original version does.