On Thu, 2016-02-04 at 10:49 +0000, George Dunlap wrote: > On Thu, Feb 4, 2016 at 8:51 AM, Yu, Zhang <yu.c.zh...@linux.intel.com> > wrote: > > > Going forward, we probably will, at some point, need to implement a > > > parallel "p2t" structure to keep track of types -- and probably will > > > whether end up implementing 4 separate write_dm types or not (for the > > > reasons you describe). > > > > > > > Thank you, George. Could you please elaborate more about the idea of > > "p2t"? > > So the p2m table is a partially-sparse structure designed to map pfns > to mfns. At the bottom is a 64-bit entry that contains certain bits > specified by the hardware (mfn number, permissions, other features). > There are at the moment extra bits that aren't use, and in these bits > we store information about the pfn that Xen wants to know -- among > other things, the 'type' of the gpfn. > > But as Andy pointed out, Intel are adding new features which take up > more of these bits; and at the same time, Xen has more features for > which using a p2m type is the most obvious solution. So the idea > would be to have a separate structure, similar to the p2m table, but > wouldn't be used by the hardware -- it would only be used by Xen to > map pfn to type (or whatever other information it wanted about the > gpfn). This does mean duplicating all the non-leaf nodes, as well as > doing two sparse-tree-walks rather than just one when looking up gpfn > information.
FWIW ARM already has such a structure to support xenaccess, since ARM had far fewer available bits to start with. It is not quite the same as above since it is only populated with pages for which xenaccess is in use rather than all pages (and is only consulted if we have reason to believe the page might be subject to xenaccess). FWIW it uses Xen's radix tree stuff. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
