| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] sparse M2P table
On 16/09/2009 13:49, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> 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?
Ah, I'd forgotten we guarantee that the M2P is made up of aligned 2MB
extents. That given I don't think we should bother having mapping holes
after all -- the cost of the extra page-directory entries is only ~4kB per
1GB of M2P. What I would instead do is just alias the first 2MB extent of
the M2P into every 'empty' 2MB extent of the M2P (this is just a handy
'safe' 2MB piece of memory to map in, so that (a) tools requests to map the
M2P just continue to work; and (b) so that we have no doubts about guests
possibly not handling faults on accesses into the M2P). Aliasing the first
M2P extent like that just avoids us burning another 2MB for no good reason,
to map regions of the M2P which really only contain 'garbage'.
Does that sound good?
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home