From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbxw-0004o4-1J for qemu-devel@nongnu.org; Wed, 18 May 2011 04:18:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMbxu-0003j8-P3 for qemu-devel@nongnu.org; Wed, 18 May 2011 04:18:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbxu-0003j0-I9 for qemu-devel@nongnu.org; Wed, 18 May 2011 04:18:46 -0400 Date: Wed, 18 May 2011 11:18:42 +0300 From: Gleb Natapov Message-ID: <20110518081842.GX19019@redhat.com> References: <4DD0D207.9040600@redhat.com> <4DD0D59E.2040907@siemens.com> <4DD372EB.4040904@web.de> <20110518074712.GW19019@redhat.com> <4DD37D2A.3060006@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD37D2A.3060006@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: Jan Kiszka Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Markus Armbruster , Isaku Yamahata , Alex Williamson , Gerd Hoffmann On Wed, May 18, 2011 at 10:02:50AM +0200, Jan Kiszka wrote: > 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. > But this is not a good excuse for no doing merges if kernel allows it :) > > 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. Yes, memory slot code was sort of hacked into qemu memory model. > > > > >> Yes, I could hack the third slot tracking algorithm, now into the i440fx > >> 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 also > >> 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 > -- Gleb.