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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/01/2015 09:31, Tim Deegan wrote:
> Hi,
>
> At 19:33 +0100 on 16 Jan (1421433186), Tim Deegan wrote:
>>>> - Feature compatibilty/completeness.  You pointed out yourself that
>>>>   it doesn't work with nested HVM or migration.  I think I'd have to
>>>>   add mem_event/access/paging and PCI passthrough to the list of
>>>>   features that ought to still work.  I'm resigned to the idea that
>>>>   many new features don't work with shadow pagetables. :)
>>>>
>>> The intention is that mem_event/access should still work. I haven't
>>> specifically looked at paging, but I don't see any fundamental reason
>>> why it shouldn't. PCI passthrough I suspect won't. Does nested HVM
>>> work with migration? Is it simply not acceptable to submit a feature
>>> as experimental, with known compatibility issues? I had assumed that
>>> it was, based on the nested HVM status as documented in the release
>>> notes.
>> Potentially, yes, if we have reasonable confidence that you (or
>> someone else) will work towards fixing those things.  If you can't
>> make promises yourself, perhaps you can talk to someone who can.
> It occurs to me that I should make the distinction between migration
> and passthrough, which are first-class features, and the others, which
> are 'preview'.  So migration and passthrough are hard requirements,
> and the others should have a bit more room for negotiation.
>
> Our process around all this is far from clear, which I can see must be
> frustrating to work with.  I wonder whether we can make some clearer
> guidelines.

I think a useful starting point would be an in-tree document stating the
hypervisor features, their support status, a short description (of a
technical orientation, including interaction with other features), a
list of remaining work to do (nice to have, or to advance to a higher
support status).

This will allow new features to more easily identify the other areas
they need to work with, and be useful as a completely unambiguous
statement as to what status a feature has, and what further is required
for it to develop.


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 :) ).

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.

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.  Logdirty would need
to be extended to cover the p2ms themselves, and p2m permissions would
also need to be sent.

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.


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

~Andrew

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