| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] sparse M2P table
>>> 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).
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
|
|
|
| |
|
Home