Re: [Qemu-devel] Why does -device qxl-vga not suppress default vga?

[Gleb Natapov <gleb@redhat.com>]

On Wed, May 18, 2011 at 09:19:07AM +0200, Jan Kiszka wrote:
> On 2011-05-17 09:52, Markus Armbruster wrote:
> > Jan Kiszka <jan.kiszka@siemens.com> 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.