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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 09/01/2015 22:21, Ed White wrote:
> On 01/09/2015 02:06 PM, Andrew Cooper wrote:
>> On 09/01/2015 21:26, Ed White wrote:
>>> This set of patches adds support to hvm domains for EPTP switching by creating
>>> multiple copies of the host p2m (currently limited to 10 copies).
>>>
>>> The primary use of this capability is expected to be in scenarios where access
>>> to memory needs to be monitored and/or restricted below the level at which the
>>> guest OS page tables operate. Two examples that were discussed at the 2014 Xen
>>> developer summit are:
>> Given the nature of VMFUNC, I presume this series is looking to add
>> support for in-guest entities to be able to monitor/tweak/swap the EPT
>> tables under the feet of operating system around it?
>>
> Primarily, yes.

Cool!  It might be helpful to add a sentence or two to this effect in
the description.

> There is (untested) support for using these capabilities
> cross-domain, because we have been contacted by multiple people who are
> interested in using them that way, but the hardware acceleration provided
> by VMFUNC and #VE aren't available cross-domain.
>
>>>     VM introspection: 
>>>         http://www.slideshare.net/xen_com_mgr/
>>>         zero-footprint-guest-memory-introspection-from-xen
>>>
>>>     Secure inter-VM communication:
>>>         http://www.slideshare.net/xen_com_mgr/nakajima-nvf
>>>
>>> Each p2m copy is populated lazily on EPT violations, and only contains entries for
>>> ram p2m types. Permissions for pages in alternate p2m's can be changed in a similar
>>> way to the existing memory access interface, and gfn->mfn mappings can be changed.
>>>
>>> All this is done through extra HVMOP types.
>>>
>>> The cross-domain HVMOP code has been compile-tested only. Also, the cross-domain
>>> code is hypervisor-only, the toolstack has not been modified.
>>>
>>> The intra-domain code has been tested. Violation notifications can only be received
>>> for pages that have been modified (access permissions and/or gfn->mfn mapping) 
>>> intra-domain, and only on VCPU's that have enabled notification.
>>>
>>> VMFUNC and #VE will both be emulated on hardware without native support.
>>>
>>> This code is not compatible with nested hvm functionality and will refuse to work
>>> with nested hvm active. It is also not compatible with migration. It should be
>>> considered experimental.
>> What about shared ept, pci passthrough, ballooning, PoD or any other
>> mechanisms which involve playing games with the EPT tables behind the
>> back of the guest?
>>
>> It appears that this feature only makes sense for a plain, RAM-only VM
>> with no bells or whistles.
>>
> The intention is that only RAM will be tweaked, which is why only RAM entries
> exist in the alternate p2m's. All those other page types are still valid and
> still handled in the primary nested page fault handler, but these mechanisms
> can't modify them.
>
> Also, if any page that was previously plain old RAM is changed in the host p2m,
> one of the later patches in the series immediately removes it from all the
> alternates, so 'stale' copies in the alternates shouldn't be an issue.

Ok so the plain old ram tricks are possibly ok, but that still sounds
like shared ept and pci passthrough are still to be avoided?

Having some non-OS part of the guest swap the EPT tables and
accidentally turn a DMA buffer read-only is not going to end well.

~Andrew