This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH v2.0 1/6] Add a config option for memory hot add
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C67A6E71.91B1%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E2263E4A5B2284449EEBD0AAB751098402CD10B5EC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C67A6E71.91B1%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

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