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

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1464 bytes --]

On 04/12/2010 10:39 PM, Jeremy Fitzhardinge wrote:
> 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.
> 

Right, that's for the "ring" page, which we use to implement a ring
buffer, and we then pass mfns of the actual Xorg's composition buffers
over this ring buffer to Dom0.

Interestingly, I have never seen a garbage in any of the composition
buffers (which are directly displayed by our appviewers, so it would be
immediately visible), just like if only the mfn for the "ring" page
could be modified, but the composition buffer's mfn were somehow pinned...

This might suggest that the memory used by the composition buffers
(which are in usermode) is somehow locked?

Thanks,
j.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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