Re: [Xen-devel] Alternate p2m design specification

[Tim Deegan <tim@xxxxxxx>]

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