| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [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
Ke
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home