Re: [Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 15:01 +0000 on 17 Jan (1421503283), Andrew Cooper wrote:
> With this altp2m code, I have been thinking about migration and passthrough.
> 
> Migration and passthrough are themselves mutually exclusive features, as
> logdirty cant identify DMA writes (and the toolstack can probably be
> forgiven for not being able to wedge a real bit of hardware into the
> migration stream :) ).

Yep.

> I cant see any problem between the existing alt2pm code and passthrough,
> in the case that shared ept is not in use.  Given the number of other
> issues we have with shared ept, I don't think this is a impediment.

Indeed.  I can't see a problem even if shared EPT is in use, as the
IOMMU will use the 'host' p2m, and the no-#VE bit is available in EPTEs.

Malicious code in the guest could circumvent the altp2m restrictions
by issuing DMA, but that's independent of shared EPT.  The current
altp2m will never map any BARs in the altp2m, but there's always IOIO
and shared-memory queues to talk to the hardware.

For that matter there are the emulated devices, whose BAR accesses
will be trapped and emulated.  I wonder whether the altp2m feature
wants to have a matching restriction on emulated I/O?

> Migration on the other hand poses a number of challenges.  The altp2m
> work would require sending multiple p2ms in the stream which is
> completely incompatible with legacy migration, but will be fine in
> migration v2 where extensions can easily be made.

Extending v1 is easy enough, just not as clean.  Grab another negative
integer to tag the new data and have at it.  Agreed that it would be
a pain to have to redo some of the framing work for v2, but the actual
saving and restoring ought to be the same.

> Logdirty would need to be extended to cover the p2ms themselves, and
> p2m permissions would also need to be sent.

I'm not sure I follow you about log-dirty.  Log-dirty tracking of
guest state is already in hand; I think the altp2m state could be
pickled after the domain is paused.

How much of the altp2ms would need to be sent is not really clear --
it would be nice to have a description of the interface's intended
semantics for this discussion.  Presumably it would be enough to
normalize the altp2ms against the real one: rather than sending the
actual contents, send only the access retrictions and #VE bit, where
they differ from the main p2m, and a gfn->gfn list of remappings.

Or: declare in the interface that the altp2ms are soft state that can
be dropped on migration, with some suitable callback (#VE injection?)
to the guest when an altp2m 'view' is not available.  That depends on
whether the in-guest agent can reconstruct the state it needs from
scratch.

> As such, I do not believe migration support should be an impediment to
> the altp2m series gaining experimental status in tree. It is not
> reasonable to delay inclusion for migration v2 to be accepted, and
> frankly, the extra work to get migration working is probably as larger
> task as this basic support.

Most of the work would be the same for v1 and v2 migration, and the
fact that it's hard doesn't mean it doesn't need to happen.
I'm willing to be persuaded on this, but we ought to have explicit
agreement in advance about:
 - what needs to be fixed;
 - who is going to do the fixing and when; and
 - what happens if it's not fixed (e.g. feature gets reverted).

> In some copious free time, I will see about drafting a start to the
> document.

Thanks!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel