From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: The mfn of the frame, that holds a mlock-ed PV domU usermode page, can change Date: Mon, 12 Apr 2010 23:19:30 +0200 Message-ID: <4BC38E62.2080703@invisiblethingslab.com> References: <20100412185454.GC3671@emperor2.itldev.org> <4BC37C32.1060805@goop.org> <4BC380E2.8060605@invisiblethingslab.com> <4BC3850F.7070108@goop.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0184266406==" Return-path: In-Reply-To: <4BC3850F.7070108@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, Rafal Wojtczuk , qubes-devel@googlegroups.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0184266406== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC2F5A3E4642B82B78149382" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC2F5A3E4642B82B78149382 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: >> =20 >>> 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 memo= ry >>> from the kernel (via some kind of driver), and then map that through = to >>> dom0? >>> =20 >> Because we want to avoid modifying Xorg sources -- it normally allocat= es >> its composition buffers using malloc, and if we wanted to make it usin= g >> some kernel allocated memory (by our custom driver) we would need to >> patch the Xorg, which we obviously wanted to avoid... >> =20 >=20 > 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 xen= bus. >=20 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..= =2E This might suggest that the memory used by the composition buffers (which are in usermode) is somehow locked? Thanks, j. --------------enigBC2F5A3E4642B82B78149382 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDjmMACgkQORdkotfEW85JkACgpOXsWNmgc3F0jW4uMddKxvne JdcAniTuqfxAmo59iaATSLtwifIfB/0T =JnR0 -----END PGP SIGNATURE----- --------------enigBC2F5A3E4642B82B78149382-- --===============0184266406== 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 --===============0184266406==--