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: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH v2.0 1/6] Add a config option for memory hot add
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 08 Jul 2009 16:52:51 +0100
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 08 Jul 2009 08:54:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E2263E4A5B2284449EEBD0AAB751098402CD10B5F8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acn/n+A3yJUALD5FQNSIqtARBUwsjgAMLZJkAAHSpaAAAIrKxAAAEkpgAAJ0H2k=
Thread-topic: [PATCH v2.0 1/6] Add a config option for memory hot add
User-agent: Microsoft-Entourage/
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