Re: [Xen-devel] sparse M2P table

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 17.09.09 08:19 >>>
>The only structure in Xen that I think doesn't just work with expanding its
>virtual memory allocation and sparse-mapping is the '1:1 memory mapping'.

The frame_table really also needs compression - a 256G M2P would imply
2T of frame table, which isn't reasonable. I'm therefore using the same
indexing for 1:1 mapping and frame table.

>Because to address such large sparse memory maps, the virtual memory
>allocation would be too large. So I'm guessing the '1:1 memory map' area
>will end up divided into say 1TB strips with phys_to_virt() executing a
>radix-tree lookup to map physical address ranges onto those
>dynamically-allocated strips.

Actually, I considered anything but a simple address transformation as
too expensive (for a first cut at least), and I'm thus not using any sort
of lookup, but rather determine bits below the most significant one that
aren't used in any (valid) mfn. Thus the transformation is two and-s, a
shift, and an or.

A more involved translation (including some sort of lookup) can imo be
used as replacement if this simple mechanism turns out insufficient.

Btw., I also decided against filling the holes in the M2P table mapping -
for debuggability purposes, I definitely want to keep the holes in the
writeable copy of the table (so that invalid accesses crash rather than
causing data corruption). Instead, I now fill the holes only in the
XENMEM_machphys_mfn_list handler (and I'm intentionally using the
most recently stored mfn in favor of the first one to reduce the
chance of reference count overflows when these get passed back
to mmu_update - if the holes turn out still too large, this might need
further tuning, but otoh in such setups [as said in an earlier reply]
I think the tools should avoid mapping the whole M2P in a single
chunk, and hence immediately recurring mfn-s can serve as a good
indication to the tools that this ought to happen).

Jan


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