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

[Ed White <edmund.h.white@xxxxxxxxx>]

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

> ~Andrew
> 

Ed

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