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