I'm in the process of putting together patches to eliminate undue overhead
resulting from Xen's current assumption on a non-sparse machine address
map. After removing large holes (symmetric across all nodes) from the
machine address map and after also mapping the resulting (much smaller)
frame table sparsely (to account for smaller holes distinct for one or more
nodes), I intended to also map the P2M table sparsely. However, there's
a tools side assumption (for domain save) on this table being contiguously
populated.
While this could be relatively easily fixed in tools, I'm wondering if there
are other dependencies on this table (or its read-only equivalent readable
by all guests) to be non-sparse. In particular, while I can easily see that
Linux has always been careful to access the read-only copy of the table
with exception fixup, I don't know whether that would also apply to the
other PV OSes (Solaris, NetBSD, ???).
One alternative would be to dedicate a zero-filled 2M page for all these
holes, but I have to admit that this doesn't seem very attractive.
Another option would be to use a made-up MFN to represent the holes,
allowing Xen (once they get fed back into mmu_update) to recognize
this and simply ignore the mapping request (after all the tools should
not access these ranges anyway). This wouldn't address potential
issues of non-Linux guests with a sparse R/O M2P table though.
Other thoughts?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel