From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbTR-0004DM-Ay for qemu-devel@nongnu.org; Wed, 18 May 2011 03:47:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMbTQ-0007Wb-D6 for qemu-devel@nongnu.org; Wed, 18 May 2011 03:47:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMbTQ-0007WR-5t for qemu-devel@nongnu.org; Wed, 18 May 2011 03:47:16 -0400 Date: Wed, 18 May 2011 10:47:12 +0300 From: Gleb Natapov Message-ID: <20110518074712.GW19019@redhat.com> References: <4DD0D207.9040600@redhat.com> <4DD0D59E.2040907@siemens.com> <4DD372EB.4040904@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD372EB.4040904@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 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. 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. > 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! > > Jan > -- Gleb.