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

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

[Markus Armbruster]

VGA, cirrus-vga and vmware-svga do.  Gerd, you added it (commit
a19cbfb3), care to explain?

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

[Gerd Hoffmann]

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.

cheers,
   Gerd

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

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

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

[Markus Armbruster]

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!

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

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

[Gleb Natapov]

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.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]

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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

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

[Gleb Natapov]

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.

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

[Markus Armbruster]

Gerd Hoffmann <kraxel@redhat.com> writes:

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

docs/qdev-device-use.txt on -device with graphics devices:

    Bug: the new way doesn't work for machine type "pc", because it
    violates obscure device initialization ordering constraints.

I'm working on an update for qdev-device-use.txt, and I plan to
retest the bug.

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

[Markus Armbruster]

Gerd Hoffmann <kraxel@redhat.com> writes:

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

I took the liberty to include a fix in "[PATCH 0/3] qdev-device-use.txt
update & trivial bonus fixes".  Hope that's okay.

[...]