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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel