[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH v2.0 1/6] Add a config option for memory hot add
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |