[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Alternate p2m design specification
At 00:09 +0100 on 11 Jun (1433981379), Andrew Cooper wrote: > On 10/06/15 20:41, Ed White wrote: > > On 06/10/2015 11:23 AM, Andrew Cooper wrote: > >> Also, hardware accelerated altp2m is mutually exclusive with EPT PML, as > >> we have no way of determining which translation was in use when a gpa > >> was appended to the buffer. We are going to have to maintain a feature > >> compatibility matrix. Even for non-accelerated altp2m, the cost of > >> working out the real gpa is likely prohibitive, and we should probably > >> resort to declaring logdirty and altp2m as exclusive features. > >> > >> ~Andrew > >> > > I haven't investigated the PML code, but just to be clear, log-dirty > > without PML is compatible with altp2m. > > The logdirty code is built around the notion of a single linear idea of > a guests physical address space. Altp2m, by its very nature, introduces > non-linearities into a guests physical address space. All current users of the log-dirty code, except for PML, operate on MFNs and use the M2P to get a PFN so use for the dirty-bitmap operation. Those paths should all be able to operate with altp2m active. (IOW the single linear address space is the 'host' p2m). Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |