From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rafal Wojtczuk Subject: The mfn of the frame, that holds a mlock-ed PV domU usermode page, can change Date: Mon, 12 Apr 2010 20:54:54 +0200 Message-ID: <20100412185454.GC3671@emperor2.itldev.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1392921671==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: joanna@invisiblethingslab.com List-Id: xen-devel@lists.xenproject.org --===============1392921671== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cmJC7u66zC7hs+87" Content-Disposition: inline --cmJC7u66zC7hs+87 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Would someone on the list enlight me on the following issue, possibly relat= ed=20 to mfn management in the PV guest. Environment: xen-3.4.3, pvops 2.6.32.9 in dom0 and domU, all 64bit. Usermode code (if you are interested, at http://gitweb.qubes-os.org/gitweb/?p=3Dmainstrea= m/gui.git;a=3Dblob;f=3Dvchan/vchan/init.c;h=3Dcb2fb851c3b97804b115dbf58fd47= a30d6d0a8a3;hb=3DHEAD) in PV domU does the following: 1) gets a page via ring_ref_v=3Dmmap(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= =20 u2mfn driver (http://gitweb.qubes-os.org/gitweb/?p=3Dmainstream/gui.git;a=3Dblob;f=3Dvch= an/u2mfn/u2mfn.c;h=3D6ff113c07c50ef078ab04d9e61d2faab338357e7;hb=3DHEAD) 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... =2E..but sometimes, apparently the page that backs ring_ref_v changes: if t= he=20 domU application calls u2mfn ioctl again with ring_ref_v argument, it=20 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= =20 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 http://www.qubes-os.org/trac/ticket/16#comment:4 It would be nice if the mfn of a frame that holds a given mlock-ed usermode= =20 page could be made constant.=20 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= =20 the situation ? BTW, for Qubes it is necessary to map PV domU usermode pages in dom0;=20 particularly, map X server composition buffers. Regards, Rafal Wojtczuk The Qubes OS Project http://qubes-os.org --cmJC7u66zC7hs+87 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkvDbHwACgkQRReIvlq199Q0FQCeMXNbBoCRhtz2LBe5qSjzEHn1 tBoAn1/e04HSihzseuGfUFeDRMc45BQf =WHoy -----END PGP SIGNATURE----- --cmJC7u66zC7hs+87-- --===============1392921671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1392921671==--