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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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. 

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

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

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel