From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbj9-0007oD-Kp for qemu-devel@nongnu.org; Wed, 18 May 2011 04:03:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMbj8-0001Ua-7a for qemu-devel@nongnu.org; Wed, 18 May 2011 04:03:31 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:45369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbj7-0001UP-Nb for qemu-devel@nongnu.org; Wed, 18 May 2011 04:03:30 -0400 Message-ID: <4DD37D2A.3060006@web.de> Date: Wed, 18 May 2011 10:02:50 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD0D207.9040600@redhat.com> <4DD0D59E.2040907@siemens.com> <4DD372EB.4040904@web.de> <20110518074712.GW19019@redhat.com> In-Reply-To: <20110518074712.GW19019@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A035321274C7BF61C647145" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] Why does -device qxl-vga not suppress default vga? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Markus Armbruster , Isaku Yamahata , Alex Williamson , Gerd Hoffmann This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A035321274C7BF61C647145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-05-18 09:47, Gleb Natapov wrote: > On Wed, May 18, 2011 at 09:19:07AM +0200, Jan Kiszka wrote: >> On 2011-05-17 09:52, Markus Armbruster wrote: >>> Jan Kiszka writes: >>> >>>> On 2011-05-16 09:28, Gerd Hoffmann wrote: >>>>> On 05/13/11 16:18, Markus Armbruster wrote: >>>>>> VGA, cirrus-vga and vmware-svga do. Gerd, you added it (commit >>>>>> a19cbfb3), care to explain? >>>>> >>>>> Just forgot to add it to the list when merging. >>>>> I'll go stuff a patch into the spice patch queue. >>>>> >>>>> Does "-device VGA" work these days btw? >>>>> Last time I tries it didn't due to some init order issues. >>>> >>>> I've (mostly) fixed the PAM/SMRAM stuff that still breaks this. Will= >>>> post the series soon. >>> >>> Good to know, thanks! >> >> I'm afraid I was too optimistic. Further testing revealed a regression= >> of my series which is fundamentally coupled to the QEMU limitation of >> tracking the physical memory mapping at page level: even with lots of >> hacks applied, KVM runs out of slots in certain setups when replaying >> the original memory mapping from the i440fx cache. >> > KVM memory slot handling code doesn't do a good job of merging two > adjacent memory areas into one slot which only magnifies the small > number of slots problem. That's partly due to legacy kernels without KVM_CAP_JOIN_MEMORY_REGIONS_WORKS. > Of course guest may program i440fx in such a > way that merging will not be possible and the only way to handle such > config will be allow for more memory slots, but the only part of a gust= > that program such low level detail is BIOS and it doesn't do that. Right, that's something which would still require more work on KVM side to allow for more slots. We had this discussion recently. Still, it should not have be KVM's or vhost's or i440fx'es job to maintain their own slot tables in such details. They should be told via a CPUPhysMemoryClient callback that slot X goes away and slots Y and Z appear, or that slot X changes in some way. They should be able to rely on the core reporting the optimal set of slots. >=20 >> Yes, I could hack the third slot tracking algorithm, now into the i440= fx >> code, but that appears to be completely. I think we better finally >> renovate that QEMU area, simplifying KVM and vhost memory clients, >> allowing for correct PAM/SMRAM emulation without hacks, and ideally al= so >> saving tons of memory by reducing the number of PhysPageDesc >> (specifically with multi-GB guest memory - something the PhysPageDesc >> tree was not designed for). >> >> If anyone has good design ideas in mind or some helping hands free, >> please speak up! I think we are lucky: PhysPageDesc is an exec.c-internal thing we should be able to change without affecting other parts of QEMU. E.g. we could replace the two-level page tree with a tree of memory slots and maintain its layout in an optimal way, ie. merge adjacent slots and report changes on that base via set_memory. Jan --------------enig9A035321274C7BF61C647145 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.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3TfSoACgkQitSsb3rl5xQmsACgjq3O1XEGWI6aWhToubxGuWg7 /48Anjd6yuBita+CVpqgMj57PW+RhjD0 =rOZA -----END PGP SIGNATURE----- --------------enig9A035321274C7BF61C647145--