This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Invalid P2M entries after gnttab unmap

To: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Invalid P2M entries after gnttab unmap
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 4 Mar 2011 18:34:53 +0000
Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 04 Mar 2011 10:35:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110304170236.GB23341@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4D7114B3.9090206@xxxxxxxxxxxxx> <20110304170236.GB23341@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

>  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

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


Xen-devel mailing list