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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: How is the virt_hv_start_low used in compatible guest
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 9 Jul 2009 15:43:37 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 09 Jul 2009 00:45:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C67B5A66.F11E%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: <4A55A948020000780004C412@xxxxxxxxxxxxxxxxxx> <C67B5A66.F11E%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoAZlSLrug5jVnOTOmj/HIFHKe2wAAAFvh8AABNdjA=
Thread-topic: How is the virt_hv_start_low used in compatible guest

Keir Fraser wrote:
> On 09/07/2009 08:24, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>>>>> "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.
> We agreed for now to size the hole big enough for amount of
> memory visible
> at boot time, and compat dom0 will simply be unable to be allocated
> dynamically added memory. It is at least not a regression of existing
> support for compat dom0. We can do smarter things later if
> someone really
> cares about the limitations of this scenario.
> -- Keir

Yes, heere I made a mistake and Keir has pointed out.

Originally I thought dom0 will check the read-only m2p table for page that is 
assigned to other guest, either for foreign mapping or granting. Later Keir 
told me that the m2p table is only used for a domain's own pages. Then it is ok 
to leave the hole to contain memory that exist when booting, since page 
allocator has take consideration of the hole size also for compatible guest.

But I did meet dom0's bug if I didn't increase the hole size in compat dom0, so 
I need investigate the reason for it (originally I thought it is caused by the 
read-only m2p table size).

Yunhong Jiang
Xen-devel mailing list

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