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@xxxxxxxxxx>
Subject: Re: [Xen-devel] Invalid P2M entries after gnttab unmap
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Fri, 04 Mar 2011 14:03:51 -0500
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 04 Mar 2011 11:06:06 -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: National Security Agency
References: <4D7114B3.9090206@xxxxxxxxxxxxx> <20110304170236.GB23341@xxxxxxxxxxxxxxxxxxxxxxx>
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 12:02 PM, 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, or just map your grant refs into an MMIO hole. 

[addressed in reply to Ian's mail]

>> The unmap operation sets the p2m mapping of the GFN to INVALID_MFN.
> There's nothing else it can set it to, really, if you take away the
> thing that was there. 
>> (and it appears that replace_grant_p2m_mapping will not accept valid MFNs).
>> Most of the time, this appears to be true in testing. However, I have
>> noticed a few cases where the GFNs are valid following the unmap operation.
> That seems like a bug. 
>> This has happened when a large number of grants (1284) are being unmapped
>> due to a domain shutdown;
> Can you be more specific?  Do you mean that a domain that has mapped
> grants into its p2m is shutting down in a controlled way, and is pulling
> out all the grant mappings as it does so?  What hypercall does it use to
> unmap the grants?

I produced this in the following test scenario:

Domain 1 (HVM) is a display server that uses gntdev to map the vfb device from
domain 2 (also HVM, using fbfront). Domain 2 was shut down using xm destroy,
which triggered (via xenstore) domain 1 to unmap all of the grants. I think I
also observed this with a normal shutdown of domain 2.

> Cheers,
> Tim.
>> 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.
>> There doesn't appear to be any documentation on the intended behavior here.
>> >From the guest kernel's perspective, it makes the most sense for GFNs that
>> pointed to RAM prior to the map operation to continue to point to RAM after
>> the unmap operation - that is, the unmap fully undoes what the map did. The
>> contents of the pages (and which exact MFN they point to) aren't important.
>> -- 
>> Daniel De Graaf
>> National Security Agency

Xen-devel mailing list