[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
- To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
- From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
- Date: Wed, 8 Jul 2009 23:01:25 +0800
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 08 Jul 2009 08:03:22 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
- Thread-index: Acn/n+A3yJUALD5FQNSIqtARBUwsjgAMLZJkAAHSpaAAAIrKxAAAEkpg
- Thread-topic: [PATCH v2.0 1/6] Add a config option for memory hot add
Keir Fraser wrote:
> On 08/07/2009 15:31, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 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.
> 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