Re: [PATCH 6/6] xen-gntdev: Introduce HVM version of gntdev

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 12/14/2010 04:45 PM, Jeremy Fitzhardinge wrote:
> On 12/14/2010 06:55 AM, Daniel De Graaf wrote:
>> HVM does not allow direct PTE modification, so guest pages must be
>> allocated and used for grant mappings. If Xen does not provide an
>> auto-translated physmap, the existing direct PTE modification is more
>> efficient.
> 
> I haven't looked at this in detail, but doing a complete duplication of
> the driver doesn't seem like a great idea.
> 
> Also, Stefano and I have been working on a modification to gntdev to
> make sure that each granted page is backed with a proper struct page (so
> that direct aio works on them).  Would this help the hvm case?
> 
> Thanks,
>     J

Only if this also allocates a guest frame number that can be passed to Xen
in order to eliminate GNTMAP_contains_pte (which cannot work in HVM). I do
have a first attempt to get this version working in the PV case (I can
share it if you're interested); mapping works, but unmap currently leaves
the system in a bad state, triggering a number of BUG_ONs.

One problem that I noticed soon after posting is that Xen does not restore
the original mapping when the unmap hypercall is run; instead, it replaces
the page with one that discards writes and returns all one bits on read.
In the PV case, it seems like integrating with the balloon device would be
the proper way to request that Xen restore a real MFN under the GFNs that
used to map granted pages. I have tried to use XENMEM_populate_physmap to
request that Xen restore page mappings, but this seems to be a noop on HVM.

As an alternative to completely duplicating the module, the module could be
expanded to check xen_feature(XENFEAT_auto_translated_physmap) and perform
the correct type of mapping based on that. Eliminating PTE modification
completely will make the module more maintainable, however.

-- 
Daniel De Graaf
National Security Agency