>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>Sent: 2009年6月28日 17:48
>To: Jiang, Yunhong; Jan Beulich; Tim Deegan;
>xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: [Xen-devel] Re: [PATCH 0/6] Add memory add support to Xen
>
>On 28/06/2009 10:26, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>> BTW, we also want to have some discussion on how to support
>memory hot add.
>> The main challenges comes from ACPI.
>> When memory hot add happen, it will trigger an ACPI event.
>The ACPI driver
>> will get memory device's resource information, including
>start/end address,
>> NUMA informatin (proximity domain information) etc and in
>the end add the
>> memory to OSPM.
>> In Xen, the ACPI event will be handled firstly by Dom0 , but
>dom0 have no idea
>> of physical memory. The real memory adding should happen in Xen HV.
>>
>> There are several option to support it.
>> a) Move the ACPI event to Xen HV, that is sure to be a big changes.
>
>There's been some discussion of making Xen the OSPM instead of
>dom0 (and
>hence giving Xen an AML interpreter, etc). Could be an
>interesting thing to
>think about. I'm not sure how well it would work since there
>will still be
>aspects of platform management that dom0 is in control of and would
>logically be the OSPM for.
Yes, the ACPI is not virtualization friendly, at least not Xen arch friendly.
And it is difficult for both PM and hotplug (both CPU and memory hotplug). Or
we can split dom0 into two domain, one is as a generic driver domain, and one
is for platform domain. The platform domain will act for ACPI, IOAPIC parse
etc, while the driver domain will own all PCI devices and act as pciback (I
didn't think in deep on it still).
Maybe option 3 will be cleaner, we are still investigate it.
Thanks
Yunhong Jiang
>
> -- Keir
>
>
>
>_______________________________________________
>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
|