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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 08/07/2009 16:01, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel