Re: The mfn of the frame, that holds a mlock-ed PV domU usermode page, can change

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 04/12/2010 01:21 PM, Joanna Rutkowska wrote:
> On 04/12/2010 10:01 PM, Jeremy Fitzhardinge wrote:
>   
>> Why is it necessary to map usermode pages?  It just seems like asking
>> for trouble.  Why not make it so that the domU X server gets the memory
>> from the kernel (via some kind of driver), and then map that through to
>> dom0?
>>     
> Because we want to avoid modifying Xorg sources -- it normally allocates
> its composition buffers using malloc, and if we wanted to make it using
> some kernel allocated memory (by our custom driver) we would need to
> patch the Xorg, which we obviously wanted to avoid...
>   

The referenced code doesn't do that; it allocates some memory with with
mmap, mlocks it, uses /proc/u2mfn to get the mfn then pokes it into xenbus.

But I assume you have other code which wants to grant through the
Xorg-allocated framebufer.  That complicates things a bit, but you could
still add a device (no /proc files, please) with an ioctl which:

   1. takes a range of usermode addresses
   2. increments the page refcount for those pages
   3. returns the mfns for those pages

That will prevent the pages from being migrated while you're referring
to their mfns.  You need to add something to explicitly decrement the
refcount to prevent a memory leak, presumably at the time you tear down
the mapping in dom0.  Ideally you'd arrange to do that triggered off
unmap of the memory range (by isolating the pages in their own new vma)
so that it all gets cleaned up on process exit.

    J