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