[lkml]   [2009]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC
    >From: Eric W. Biederman
    >Sent: 2009年6月20日 16:22
    >Keir Fraser <> writes:
    >> On 20/06/2009 00:44, "Nakajima, Jun" <> 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.

     \ /
      Last update: 2009-06-20 11:07    [W:0.026 / U:12.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site