All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/6] Add memory add support to Xen
@ 2009-06-28  9:26 Jiang, Yunhong
  2009-06-28  9:47 ` Keir Fraser
  2009-06-29  3:50 ` Nakajima, Jun
  0 siblings, 2 replies; 6+ messages in thread
From: Jiang, Yunhong @ 2009-06-28  9:26 UTC (permalink / raw)
  To: Keir Fraser, Jan Beulich, Tim Deegan, xen-devel

Hi, all, this patchset add support so that we can add memory dynamically to the system. This can be used for memory hot add.

The change includes 
a) changes to boot allocator, frametable setup, m2p table setup, so that they will be called not-only when system boot up, but also when hot add happens
b) Changes to page fault handler, to propgate changes to frametable/m2p table to all guest.

Please review  it and gives feedback.

Thanks
Yunhong Jiang

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.
b) Add some hook in Dom0, so that instead of add the new memory to dom0, it will use hypercall to notify Xen HV.
c) Change current dom0 implementation. When dom0 get the ACPI event and get the memory device's resource, it will not directly add the memry to system, instead, it will notify user space with uevent. The uevent script will ask kernel to add the new memory to system. In Xen environment, the uevent script will notify Xen HV. We are still investigating on this option.

We are in early stage . any suggestion or new idea will be helpful to us and welcome.

Of course, no matter how to support memory hotadd, this patchset is not impacted . For example, following usage model will require this function: an "mem=" optoin .is used to limit xen's memory, and later, we want to bring all memory to xen.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/6] Add memory add support to Xen
  2009-06-28  9:26 [PATCH 0/6] Add memory add support to Xen Jiang, Yunhong
@ 2009-06-28  9:47 ` Keir Fraser
  2009-06-28 13:32   ` Jiang, Yunhong
  2009-06-29  1:42   ` Dan Magenheimer
  2009-06-29  3:50 ` Nakajima, Jun
  1 sibling, 2 replies; 6+ messages in thread
From: Keir Fraser @ 2009-06-28  9:47 UTC (permalink / raw)
  To: Jiang, Yunhong, Jan Beulich, Tim Deegan, xen-devel

On 28/06/2009 10:26, "Jiang, Yunhong" <yunhong.jiang@intel.com> 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.

 -- Keir

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [PATCH 0/6] Add memory add support to Xen
  2009-06-28  9:47 ` Keir Fraser
@ 2009-06-28 13:32   ` Jiang, Yunhong
  2009-06-29  1:42   ` Dan Magenheimer
  1 sibling, 0 replies; 6+ messages in thread
From: Jiang, Yunhong @ 2009-06-28 13:32 UTC (permalink / raw)
  To: Keir Fraser, Jan Beulich, Tim Deegan, xen-devel

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

 

>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com 
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
>Sent: 2009年6月28日 17:48
>To: Jiang, Yunhong; Jan Beulich; Tim Deegan; 
>xen-devel@lists.xensource.com
>Subject: [Xen-devel] Re: [PATCH 0/6] Add memory add support to Xen
>
>On 28/06/2009 10:26, "Jiang, Yunhong" <yunhong.jiang@intel.com> 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@lists.xensource.com
>http://lists.xensource.com/xen-devel
>

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: Re: [PATCH 0/6] Add memory add support to Xen
  2009-06-28  9:47 ` Keir Fraser
  2009-06-28 13:32   ` Jiang, Yunhong
@ 2009-06-29  1:42   ` Dan Magenheimer
  1 sibling, 0 replies; 6+ messages in thread
From: Dan Magenheimer @ 2009-06-29  1:42 UTC (permalink / raw)
  To: Keir Fraser, Jiang, Yunhong, Jan Beulich, Tim Deegan, xen-devel

I seem to recall that an AML interpreter is larger than
an entire hypervisor.  This was a few years ago so may
not still be valid, but if it is anywhere near true,
it seems like a potential issue. :-)

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
> Sent: Sunday, June 28, 2009 3:48 AM
> To: Jiang, Yunhong; Jan Beulich; Tim Deegan;
> xen-devel@lists.xensource.com
> Subject: [Xen-devel] Re: [PATCH 0/6] Add memory add support to Xen
> 
> 
> On 28/06/2009 10:26, "Jiang, Yunhong" <yunhong.jiang@intel.com> 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.
> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [PATCH 0/6] Add memory add support to Xen
  2009-06-28  9:26 [PATCH 0/6] Add memory add support to Xen Jiang, Yunhong
  2009-06-28  9:47 ` Keir Fraser
@ 2009-06-29  3:50 ` Nakajima, Jun
  2009-06-29  5:58   ` Jiang, Yunhong
  1 sibling, 1 reply; 6+ messages in thread
From: Nakajima, Jun @ 2009-06-29  3:50 UTC (permalink / raw)
  To: Jiang, Yunhong, Keir Fraser, Jan Beulich, Tim Deegan, xen-devel

Jiang, Yunhong wrote on Sun, 28 Jun 2009 at 02:26:51:

> 
> There are several option to support it.
> a) Move the ACPI event to Xen HV, that is sure to be a big changes.
> b) Add some hook in Dom0, so that instead of add the new memory to dom0,
> it will use hypercall to notify Xen HV.
> c) Change current dom0 implementation. When dom0 get the ACPI event and
> get the memory device's resource, it will not directly add the memry to
> system, instead, it will notify user space with uevent. The uevent
> script will ask kernel to add the new memory to system. In Xen
> environment, the uevent script will notify Xen HV. We are still
> investigating on this option.
> 
> We are in early stage . any suggestion or new idea will be helpful to
> us and welcome.
> 

I think the option b is the practical choice because the kernel typically has a well-defined routine for that, and the maintenance cost of the diff for dom0 should be very low. The option c may not work for other OS like Solaris...

Jun
___
Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [PATCH 0/6] Add memory add support to Xen
  2009-06-29  3:50 ` Nakajima, Jun
@ 2009-06-29  5:58   ` Jiang, Yunhong
  0 siblings, 0 replies; 6+ messages in thread
From: Jiang, Yunhong @ 2009-06-29  5:58 UTC (permalink / raw)
  To: Nakajima, Jun, Keir Fraser, Jan Beulich, Tim Deegan, xen-devel


Nakajima, Jun wrote:
> Jiang, Yunhong wrote on Sun, 28 Jun 2009 at 02:26:51:
> 
>> 
>> There are several option to support it.
>> a) Move the ACPI event to Xen HV, that is sure to be a big changes.
>> b) Add some hook in Dom0, so that instead of add the new memory to
>> dom0, it will use hypercall to notify Xen HV.
>> c) Change current dom0 implementation. When dom0 get the ACPI event
>> and get the memory device's resource, it will not directly add the
>> memry to system, instead, it will notify user space with uevent. The
>> uevent script will ask kernel to add the new memory to system. In Xen
>> environment, the uevent script will notify Xen HV. We are still
>> investigating on this option. 
>> 
>> We are in early stage . any suggestion or new idea will be helpful
>> to us and welcome. 
>> 
> 
> I think the option b is the practical choice because the
> kernel typically has a well-defined routine for that, and the
> maintenance cost of the diff for dom0 should be very low. The
> option c may not work for other OS like Solaris...

Yes, the diff will be low. We will work on this way.

--jyh

> 
> Jun
> ___
> Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-06-29  5:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-28  9:26 [PATCH 0/6] Add memory add support to Xen Jiang, Yunhong
2009-06-28  9:47 ` Keir Fraser
2009-06-28 13:32   ` Jiang, Yunhong
2009-06-29  1:42   ` Dan Magenheimer
2009-06-29  3:50 ` Nakajima, Jun
2009-06-29  5:58   ` Jiang, Yunhong

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.