On 03/04/2011 12:02 PM, Tim Deegan wrote:
> 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.
>> 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