RE: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICsjust because there's no local APIC

[Tian, Kevin]

>From: Eric W. Biederman
>Sent: 2009年6月20日 16:22
>
>Keir Fraser <keir.fraser@xxxxxxxxxxxxx> writes:
>
>> On 20/06/2009 00:44, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> wrote:
>>
>>>> I assume that putting AML into Xen has been considered, but I don't
>>>> anything about those deliberations.  Keir? Jun?
>>>> 
>>> 
>>> Yes, it was one of the options years ago. We did not do 
>that because Linux and
>>> Solaris (as dom0) already had the AML interpreter and it's 
>overkill and
>>> redundant to have such a large component in the Xen 
>hypervisor. Since the
>>> hypervisor does most of the power management (i.e. P, C, 
>S-state, etc.)
>>> getting the info from dom0 today, we might want to 
>reconsider the option.
>>
>> Yes, we could reconsider. However is there any stuff that 
>dom0 remains
>> responsible for (e.g., PCI management, and therefore PCI 
>hotplug) where it
>> would continue to need to be OSPM, interpreting certain AML 
>objects? In
>> general how safe would it be to have two layered entities 
>both playing at
>> being OSPM?
>
>Short of running the oddball acpi based drivers.  I'm not familiar with
>any acpi in the pci management.
>

PCIe hotplug is defined well by its own BUS spec. But conventional
PCI hotplug is implemented all kinds of strange things. Some is
through ACPI, and thus by moving ACPI into Xen, a new 'virtual' hotplug
architecture has to be introduced into dom0 Linux. Or Xen needs to 
emulate some known interface but as said there's no common standard
for PCI hotplug. What's worse is the docking station support which 
contains diverse legacy devices. How Xen pass those legacy device 
hotplug events into dom0 Linux become another gray area suffering from 
same question like whether IOAPIC needs to be changed for Xen...

Above comes from the exclusive assumption that ACPI is removed
from dom0 by moving into Xen.

Another choice is to have two layered ACPI in both dom0 and Xen
with dom0's ACPI virtualized a bit by Xen. However it's messy as 
ACPI encodes most stuff in its own AML encode as a gray box. 
Many ACPI methods talk to hardware bits internally even by hard 
coded I/O registers. You don't know whether one ACPI event 
should be handled by Xen or not, until some AML methods have 
been evaluated which then may already consume and change 
some device states and not reversible. Then Xen have to emulate 
those states when injecting a virtual ACPI event into dom0 as 
dom0 ACPI methods need to consume same states. However
automatic generating emulation code for diverse ACPI implementations
to me is far more complex than any discussion here. 

So the real trouble is ACPI , which encode all platform bits if 
they're not included in any existing BUS spec, such as power, 
thermal, processor, battery, PCI routing, hotplug, EC, etc. Some
are owned by dom0 and some by Xen. However ACPI's AML encoding
makes automatic division between two categories really difficult.

Thanks,
Kevin韬{.n?????%?lzwm?b?Р骒r?zXЩ??{ay????j?f＂?????ア?⒎?:+v???????赙zZ+????"?!?O???v??m?鹈n?帼Y&—