From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N56lY-00054s-G9 for qemu-devel@nongnu.org; Mon, 02 Nov 2009 18:56:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N56lW-00054P-FL for qemu-devel@nongnu.org; Mon, 02 Nov 2009 18:56:51 -0500 Received: from [199.232.76.173] (port=53772 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N56lW-00054C-9Y for qemu-devel@nongnu.org; Mon, 02 Nov 2009 18:56:50 -0500 Received: from smtp1.kolej.mff.cuni.cz ([78.128.192.10]:61562) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N56lV-0006HX-LY for qemu-devel@nongnu.org; Mon, 02 Nov 2009 18:56:50 -0500 Date: Tue, 3 Nov 2009 00:57:33 +0100 From: Ondrej Zajicek Message-ID: <20091102235733.GB28292@localhost> References: <1257199759-2941-1-git-send-email-agraf@suse.de> <20091102223249.GC22301@localhost> <5B01907D-86BE-4693-81BA-23CB81B8B047@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline In-Reply-To: <5B01907D-86BE-4693-81BA-23CB81B8B047@suse.de> Subject: [Qemu-devel] Re: [Linux-fbdev-devel] [PATCH] Add VirtIO Frame Buffer Support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: linux-fbdev-devel@lists.sourceforge.net, qemu-devel , kvm list --Yylu36WmvOXNoKYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 03, 2009 at 12:24:15AM +0100, Alexander Graf wrote: >> Also, we still need to keep the local frame buffer copy in sync so we >> can mmap and read from it, right? So it's not really worth it >> probably... > > But then again we could just try to be closer to a real graphics card. = =20 > What if we'd set up a memory region on the host that is basically our =20 > graphics frame buffer? For S390 we could just append the graphics memory= =20 > to the guest's memory. > > We could use that as backing buffer in the qemu graphics frontend and as= =20 > frame buffer in the Linux fbdev layer, similar to what real graphics=20 > cards set up. Using shared memory pages between host and guest seems like a natural way to implement paravirtualized graphics card. Most things are straightforward, only a little problematic thing is when fbdev=20 is mmaped from guest to userspace - you have to detect writes and notify host that it changed. --=20 Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrvce0ACgkQw1GB2RHercP9swCfR8R9+phVoIUB2pG+3AMCPJDn J8sAn0FpRm3LSI9y6ycFug0gCsU8lY2n =6PAz -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn--