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: How is the virt_hv_start_low used in compatible guest

To: <yunhong.jiang@xxxxxxxxx>
Subject: [Xen-devel] RE: How is the virt_hv_start_low used in compatible guest
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 09 Jul 2009 08:24:39 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, keir.fraser@xxxxxxxxxxxxx
Delivery-date: Thu, 09 Jul 2009 00:25:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 07/08/09 9:22 AM >>>
>When consider the memory add situation, the size can't be
>adjusted, so I disable this adjustment if we support memory
>add, do you think it is ok? 

I wouldn't welcome this - instead, the maximum range of
memory ever expected to be added should be controlled by a
command line option for that purpose. And even without such,
instead of completely avoiding the adjustment, it should be
done assuming the maximum amount a 32-bit domain would
ever get to see (128Gb), which would still make the hole
smaller than it is on a 32-bit hv.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>