This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] HVM PIC/APIC confusion in ACPI firmware?

To: "David Lively" <dlively@xxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] HVM PIC/APIC confusion in ACPI firmware?
From: "Yu, Ke" <ke.yu@xxxxxxxxx>
Date: Wed, 27 Sep 2006 20:10:45 +0800
Delivery-date: Wed, 27 Sep 2006 05:11:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbhmIQ1NKvewar9QOuI0SbZ0rT60gAk9PMQ
Thread-topic: [Xen-devel] HVM PIC/APIC confusion in ACPI firmware?
Hi David, 

Good description of the logic. From your decription, you can actually
see current code is correct.  PRTP consists of "link device" and is for
PIC mode. PRTA is for APIC mode.  PRTA currently only contain entries
for existed device. If qemu introduces new device in the future, new
entry can be added to PRTA accordingly.   

Best Regards

David Lively wrote:
> 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. 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>