Xen devel - Jul 2009 - [PATCH v2.0 1/6] Add a config option for memory hot add

This patch add an option for memory hot add.

Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>

diff -r d5c97cd22d6f xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h	Thu Jun 25 14:30:00 2009 +0100
+++ b/xen/include/asm-x86/config.h	Thu Jun 25 21:40:56 2009 +0800
@@ -41,6 +41,10 @@
 
 #define CONFIG_HOTPLUG 1
 #define CONFIG_HOTPLUG_CPU 1
+#define CONFIG_MEMORY_HOTPLUG   1
+
+/* In x86_32, we support only 16G at most */
+#define X86_MAX_PFN  (16UL << (30 - PAGE_SHIFT))
 
 #define HZ 100
 


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

On 08/07/2009 08:44, "Jiang, Yunhong" <yunhong.jiang@intel.com>
wrote:
> This patch add an option for memory hot add.
> 
> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Doesn''t need to be a config option. We only have some CONFIG_* options
to
avoid modifying Linux-derived files. For new Xen features, don''t
bother. Add
X86_MAX_PFN in the patch that uses it, and if it is x86_32 only then it
should only be defined for that build target (not x86_64 as well).

 -- Keir



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

Keir Fraser wrote:
> On 08/07/2009 08:44, "Jiang, Yunhong"
<yunhong.jiang@intel.com> wrote:
> 
>> This patch add an option for memory hot add.
>> 
>> Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
> 
> Doesn''t need to be a config option. We only have some CONFIG_*
> options to
> avoid modifying Linux-derived files. For new Xen features,
> don''t bother. Add
> X86_MAX_PFN in the patch that uses it, and if it is x86_32 only then
> it should only be defined for that build target (not x86_64 as well).
Sorry that I didn''t realize the purpose of the CONFIG_* options. But
this optoin may be needed because:
a) When memory hotplug, we need set the boot allocation bitmap memory to 512k
when booting. So for small system, we can avoid that extra memory. Of course,
maybe that can be removed after the allocation bitmap is removed al-together.
b) When Memory hotplug, we can''t adjust compatible guest''s
hv_virt_start anymore. I''m not sure how important it is, so I keep that
for non-memory-hotplug support.

Any idea?

I will change the X86_MAX_PFN.
> 
> -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/07/2009 15:31, "Jiang, Yunhong" <yunhong.jiang@intel.com>
wrote:
> Sorry that I didn''t realize the purpose of the CONFIG_* options.
But this
> optoin may be needed because:
> a) When memory hotplug, we need set the boot allocation bitmap memory to
512k
> when booting. So for small system, we can avoid that extra memory. Of
course,
> maybe that can be removed after the allocation bitmap is removed
al-together.
> b) When Memory hotplug, we can''t adjust compatible
guest''s hv_virt_start
> anymore. I''m not sure how important it is, so I keep that for
> non-memory-hotplug support.
Can you explain the reasons for these limitations? I can''t see why
either
would be strictly necessary.

Also if you limit the bitmap memory to 512k during boot that wouldn''t
be
great since it limits us to 16GB doesn''t it?

Another thought: you should kill x86_32 support if it simplifies your
patches. We really only need to support these big-iron features on x86_64 --
nearly everyone should be able to happily run x86_64 Xen by now.

 -- Keir
> Any idea?
> 
> I will change the X86_MAX_PFN.


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

Keir Fraser wrote:
> On 08/07/2009 15:31, "Jiang, Yunhong"
<yunhong.jiang@intel.com> wrote:
> 
>> Sorry that I didn''t realize the purpose of the CONFIG_*
options. But
>> this optoin may be needed because: a) When memory hotplug, we need
>> set the boot allocation bitmap memory to 512k when booting. So for
>> small system, we can avoid that extra memory. Of course, maybe that
>> can be removed after the allocation bitmap is removed al-together.
>> b) When Memory hotplug, we can''t adjust compatible
guest''s
>> hv_virt_start anymore. I''m not sure how important it is, so I
keep
>> that for non-memory-hotplug support. 
> 
> Can you explain the reasons for these limitations? I can''t see
> why either
> would be strictly necessary.
> 
> Also if you limit the bitmap memory to 512k during boot that
> wouldn''t be
> great since it limits us to 16GB doesn''t it?
That is only for x86_32 version since we only support 16G at most in x86_32. For
x86_64, we didn''t change that. Instead we remap the bitmap to another
virtual address. While it is difficult to add free virtual address for bitmap
now in x86_32, the whole 168M is caculated so carefully.

For compatibility mode, the range between HYPERVISOR_COMPAT_VIRT_START ~
MACH2PHYS_COMPAT_VIRT_END will cover point to the read-only m2p table. Currently
it is adjustable, so the size of this range is determined by the memory size
when system booting. However, when we add more memory to the system, guest
(mainly dom0) can''t get the mapping for new memory anymore.

Thanks
Yunhong Jiang

> 
> Another thought: you should kill x86_32 support if it simplifies your
> patches. We really only need to support these big-iron
> features on x86_64 --
> nearly everyone should be able to happily run x86_64 Xen by now.
> 
> -- Keir
> 
>> Any idea?
>> 
>> I will change the X86_MAX_PFN.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/07/2009 16:01, "Jiang, Yunhong" <yunhong.jiang@intel.com>
wrote:
>> Also if you limit the bitmap memory to 512k during boot that
>> wouldn''t be
>> great since it limits us to 16GB doesn''t it?
> 
> That is only for x86_32 version since we only support 16G at most in
x86_32.
> For x86_64, we didn''t change that. Instead we remap the bitmap to
another
> virtual address. While it is difficult to add free virtual address for
bitmap
> now in x86_32, the whole 168M is caculated so carefully.
Okay, firstly I now got rid of bitmap allocator after boot (changeset
19913). That should simplify your patches a fair bit. Secondly, we do not
care about supporting x86_32 for this feature: simply stub out your
implementation for x86_32 and support x86_64 only. Unless there are
basically no code differences required for supporting x86_32.
> For compatibility mode, the range between HYPERVISOR_COMPAT_VIRT_START ~
> MACH2PHYS_COMPAT_VIRT_END will cover point to the read-only m2p table.
> Currently it is adjustable, so the size of this range is determined by the
> memory size when system booting. However, when we add more memory to the
> system, guest (mainly dom0) can''t get the mapping for new memory
anymore.
Then you can''t allocate such memory to a compat guest. That''s
fine. It''s
obviously no worse than not enabling memory hotplug at all.

Disabling the dynamic hv_virt_start is stupid though -- you may as well at
least let a compat guest use as much memory as possible that is visible at
boot time, right? Even though it can''t be dynamically expanded later?

 -- Keir



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