From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDF6z-0006KD-68 for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:56:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDF6u-0006Hi-Ln for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:56:20 -0400 Received: from [199.232.76.173] (port=56454 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDF6u-0006Hc-8R for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:56:16 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:33452) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDF6t-0006Nc-J9 for qemu-devel@nongnu.org; Sun, 07 Jun 2009 05:56:15 -0400 Message-ID: <4A2B8EBA.3020402@web.de> Date: Sun, 07 Jun 2009 11:56:10 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4A26F1E3.1040509@codemonkey.ws> <4A2A92FE.2010700@redhat.com> <4A2AA10B.6060401@web.de> <4A2B49C0.8020703@redhat.com> <4A2B6DD8.3090104@web.de> <4A2B7F5E.8050807@web.de> <4A2B8787.5080603@web.de> <4A2B8A4D.3010703@redhat.com> <4A2B8CB5.9040403@web.de> <4A2B8DD4.5060500@redhat.com> In-Reply-To: <4A2B8DD4.5060500@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6250D3537D9831BA683FAF60" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: POLL: Why do you use kqemu? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6250D3537D9831BA683FAF60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Jan Kiszka wrote: >> Avi Kivity wrote: >> =20 >>> Jan Kiszka wrote: >>> =20 >>>>>> Check e.g the diff of hw/vga.c against upstream: All the magic dan= ces >>>>>> there are required as qemu-kvm tracking >>>>>> cpu_register_physical_memory and >>>>>> kvm_log_start cannot cope with all the patterns normal qemu code >>>>>> comes >>>>>> up with. Upstream slot management now provides the same features >>>>>> (including migration) like qemu-kvm, it just does not deal with >>>>>> legacy, >>>>>> thus it does not have to patch qemu code (rather, we were able to= >>>>>> remove >>>>>> some already merged hooks - vga_dirty_log_stop). >>>>>> =20 >>>>> Still not very restrictive, all this could be encapsulated with for= >>>>> example macro COMPAT_NO_DMRW which could be removed when we don't c= are >>>>> anymore. Next? >>>>> =20 >>>> Really, it's not worth the maintenance pain: Every new device emulat= ion >>>> code that wants to be KVM-legacy-compatible would need to be written= >>>> like that. And unless you are familiar with the slot management >>>> internals, the "correct" pattern will not be obvious. >>>> =20 >>> Only devices which direct map memory. Currently VGA and cirrus. >>> >>> =20 >> >> --- /data/qemu/hw/piix_pci.c 2009-06-07 09:42:27.000000000 +0200 >> +++ hw/piix_pci.c 2009-06-02 13:00:09.000000000 +0200 >> ... >> @@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping >> int i, r; >> uint32_t smram, addr; >> >> + if (kvm_enabled()) { >> + /* FIXME: Support remappings and protection changes. */ >> + return; >> + } >> update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3); >> for(i =3D 0; i < 12; i++) { >> r =3D (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3; >> >> IIRC, this is at least partially due to the restricted slot management= >> in qemu-kvm - or is this obsolete now? >> =20 >=20 > This is from the first days of qemu-kvm, some of this is due to Intel > real mode issues (can't start at 0xffff ffff ffff fff0), and some I > never got around to. It's possible that it requires proper slot > destruction. Even if that's the case, we cam simply return here, as th= e > code shows. But we can also get past this point as upstream demonstrates (minus protection changes). Jan --------------enig6250D3537D9831BA683FAF60 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkorjroACgkQniDOoMHTA+kAYgCdEWgQYGNkiOQIWIZYMXn8GCXS YyEAnih33zBdJwqWkYp702KBMRefuIk4 =Vsmf -----END PGP SIGNATURE----- --------------enig6250D3537D9831BA683FAF60--