This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] The mfn of the frame, that holds a mlock-ed PV domU usermode

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] The mfn of the frame, that holds a mlock-ed PV domU usermode page, can change
From: Rafal Wojtczuk <rafal@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 12 Apr 2010 20:54:54 +0200
Cc: joanna@xxxxxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 12 Apr 2010 11:56:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)
Would someone on the list enlight me on the following issue, possibly related 
to mfn management in the PV guest.
Environment: xen-3.4.3, pvops in dom0 and domU, all 64bit.
Usermode code
(if you are interested, at 
in PV domU does the following:
1) gets a page via
ring_ref_v=mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE |MAP_ANON,-1, 0);
2) mlock(ring_ref_v, 4096)
3) determines the mfn number of the frame holding ring_ref_v via a call to 
u2mfn driver
the driver basically does get_user_pages+kmap+virt_to_mfn (and later
kunmap+put_page for cleanup).

Then, the
usermode code in dom0 does xc_map_foreign_range on the returned mfn, and can
communicate with the code in domU over this shared page...
...but sometimes, apparently the page that backs ring_ref_v changes: if the 
domU application calls u2mfn ioctl again with ring_ref_v argument, it 
returns a different mfn.
And naturally the code in dom0 reads garbage from the address returned by
its pevious call to xc_map_foreign_range.

I find it puzzling. Is this behaviour normal/expected ?
Mlock man pages say "All pages that contain a part of the specified address 
range are guaranteed to be resident in RAM", not "be resident at the same
RAM location", but why would a frame backing a mlock-ed memory be changed ?
Is there some memory defragmentation going on ? Or maybe only frame->frame
number function changes (but why would it) ?

Anyway, this behaviour causes problems, as you can see in
It would be nice if the mfn of a frame that holds a given mlock-ed usermode 
page could be made constant. 

If you can offer some insight, that would be helpful, particularly:
1) Why this does not happen to pages allocated in kernel mode (if it did, it
would break the split drivers model) ?
2) Can this frame-changing behaviour be switched off at Xen/kernel level?
3) Would using grant tables (instead of brutal xc_map_foreign_range) change 
the situation ?
BTW, for Qubes it is necessary to map PV domU usermode pages in dom0; 
particularly, map X server composition buffers.

Rafal Wojtczuk
The Qubes OS Project

Attachment: pgpjdutVy9dUx.pgp
Description: PGP signature

Xen-devel mailing list