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

[Gleb Natapov <gleb@redhat.com>]

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 <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.
> 
> 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.