[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "David Lively" <dlively@xxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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
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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.