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: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Invalid P2M entries after gnttab unmap
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Fri, 04 Mar 2011 14:03:52 -0500
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 04 Mar 2011 11:04:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1299263693.13328.9.camel@xxxxxxxxxxxxxxxxxxxxx>
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: National Security Agency
References: <4D7114B3.9090206@xxxxxxxxxxxxx> <20110304170236.GB23341@xxxxxxxxxxxxxxxxxxxxxxx> <1299263693.13328.9.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7
On 03/04/2011 01:34 PM, Ian Campbell wrote:
> 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?

Yes, remapping seems to be useless unless there's a "somewhere else" that
isn't usable for normal memory access.

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

I recall having problems with doing this last time, but I think other changes
to make the balloon driver work in HVM may have fixed the issue. I'll try it
again; I think this would be the best solution.

It may be useful to integrate with the balloon driver and use some of the pages
that have already been ballooned down, rather than forcing the map to be a two-
step process. This would also make handling a failure to balloon back up far
easier. This would add a dependency on the balloon module and a new interface
that allows requesting/returning ballooned pages.

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

Agreed, it would be best to avoid this workaround since the intended behavior
of unmapping is to produce invalid PFNs (I had written it assuming they were
intended to be valid). Using the ballooning hypercalls should fix this.

Daniel De Graaf
National Security Agency

Xen-devel mailing list