Re: Invalid P2M entries after gnttab unmap

[Ian Campbell <Ian.Campbell@eu.citrix.com>]

On Fri, 2011-03-04 at 17:02 +0000, Tim Deegan wrote:
> Hi, 
> 
> At 16:34 +0000 on 04 Mar (1299256499), Daniel De Graaf wrote:
> > When an HVM guest uses gnttab_map_grant_ref to map granted on top of valid
> > GFNs, it appears that the original MFNs referred to by these GFNs are lost.
> 
> Yes.  The p2m table only holds one MFN for each PFN (and vice versa).
> If you want to keep that memory you could move it somewhere else 
> using XENMAPSPACE_gmfn,

In which case you might as well do the grant map to "somewhere else" I
guess?

>  or just map your grant refs into an MMIO hole. 

The platform-pci device has a BAR for this sort of purpose, doesn't it?
Mostly it just gets used for the grant table itself and perhaps it isn't
large enough to be a suitable source of mapping space.

Is there some reason the gntdev driver can't just balloon down
(XENMEM_decrease_reservation) to make itself a space to map and then
balloon back up (XENMEM_increase_reservation) after unmap when running
HVM?

> > in this case, perhaps half of the unmapped GFNs
> > will point to valid memory, and half will point to invalid memory. In this
> > case, "invalid memory" discards writes and returns 0xFF on all reads; valid
> > memory appears to be normal RAM.

The workaround relies entirely on this discard and read 0xff behaviour,
which I'm not sure is wise.

I'm not especially happy about the idea of 2.6.39 getting released into
the wild with this hack in it. Luckily there is plenty of time to fix
the issue properly before then.

Ian.