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


[Xen-devel] Invalid P2M entries after gnttab unmap

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>
Subject: [Xen-devel] Invalid P2M entries after gnttab unmap
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Fri, 04 Mar 2011 11:34:59 -0500
Delivery-date: Fri, 04 Mar 2011 08:35:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
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
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.
The unmap operation sets the p2m mapping of the GFN to INVALID_MFN (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.
This has happened when a large number of grants (1284) are being unmapped
due to a domain shutdown; 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