WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [PATCH v2.0 0/6] Add memory add support to Xen

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH v2.0 0/6] Add memory add support to Xen
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 10 Jul 2009 16:58:30 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 10 Jul 2009 02:01:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A571D290200007800009C91@xxxxxxxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098402CD17422E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C67CBC85.F48B%keir.fraser@xxxxxxxxxxxxx> <4A571D290200007800009C91@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoBO6OjMoicjVFDSYW7iGcc+zjNxQAAL/Rg
Thread-topic: [Xen-devel] Re: [PATCH v2.0 0/6] Add memory add support to Xen
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote:
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 10.07.09 10:38 >>>
>> On 10/07/2009 09:32, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
>> wrote: 
>> 
>>>> This for x86/64 guests of course. We already established that
>>>> compat guests and memory add are going to have lesser mutual
>>>> support. 
>>> 
>>>  I checked this before and I thought it is ok.
>>> Currently the machine_to_phys_order is caculated based on return
>>> value of XENMEM_machphys_mapping. For both x86_32 and non-compat
>>> x86_64, this size will not be adjusted dynamically, so it is ok (it
>>> will cover the whole possible range). The only issue is for
>>> compatible domain. For compatible domain, the value returned in
>>> XENMEM_machphys_mapping is adjusted (i.e.
>>> MACH2PHYS_COMPAT_VIRT_START(d)). However, 
> domain_clamp_alloc_bitsize() in
>>> domainheap allocator will make sure the hot-added memory will not
>>> be assigned to the guest. 
>>> 
>>> Did I miss-understand something?
>> 
>> Sounds okay to me. Perhaps Jan has other thoughts?
> 
> Oh, indeed - somehow I (incorrectly) recalled that this hypercall
> returned the actually used boundary rather than the highest possible
> one. With me being wrong here, all should be fine with that change.
> 
> Sorry for the noise,
> Jan

Thanks for your review and consideration indeed !

--jyh

> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel