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] sparse M2P table

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] sparse M2P table
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Thu, 17 Sep 2009 13:42:45 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Sep 2009 22:45:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB0FB08020000780001567B@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: <4AB0E2A9020000780001563B@xxxxxxxxxxxxxxxxxx> <C6D69852.14E6A%keir.fraser@xxxxxxxxxxxxx> <4AB0FB08020000780001567B@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aco2zHFIneI0pKnDRdyHyRpCp0lLzwAilRgw
Thread-topic: [Xen-devel] sparse M2P table
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote:
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 16.09.09 14:27 >>>
>> On 16/09/2009 12:05, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> 
>>>> The guest P2Ms? Why would you want to do that - so that you can
>>>> add some hierarchy (and therefore sparseness) to the pseuo-phys
>>>> address space too? Otherwise I don't see why you would ever have a
>>>> sparse P2M, and therefore why you would care about efficiently
>>>> handling large holes in it. 
>>> 
>>> Oh, typo (see subject) - I really mean the M2P table here. The P2M
>>> table has no reason to be sparse.
>> 
>> Ah okay, that makes more sense! I think M2P should be mapped
>> sparsely and we should expect guests to deal with it. We can revise
>> that opinion if we find strong reason to do otherwise. It's
>> certainly what I was intending to do. 
> 
> So for domain save, would you think that passing out zeroes
> for the holes
> in the output of XENMEM_machphys_mfn_list is a reasonable thing to do,
> with the expectation that the tools would split up their
> mapping request
> when encountering zeroes (single mmap(), but multiple subsequent
> calls through privcmd)? 
> 
> Or shouldn't the tools perhaps not even do this with a single mmap()
> anymore, as the table can be pretty much unbounded now (I'm limiting
> it to 256G in my patches, but that doesn't need to be the final
> limit). 

I'm working on similar staff also, mainly because of memory hotplug requires 
such support. Maybe I can base my work on your work :-)

256G is not enough if memory hotplug is enabled. In some platform, user can set 
the start address for hotpluged memory and the default value is 1024G. That 
means 4M memory will be used for the L3 table entries (1024 * 4K).

I'm not sure Keir's "sparse-memory x86 systems are in the pipeline" is about 
memory hotplug also?  Will there be sparse memory when the system boot up? 
Currently I didn't change the m2p setup code when paging init, instead, I just 
add new sparse m2p table when hot-add happens.

--jyh

> 
> Also, will it be okay to leave the tools side stuff to be done
> by someone
> more familiar with them than I am?
> 
> Jan
> 
> 
> _______________________________________________
> 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