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

[Jan Kiszka]

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 <address@hidden> 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

signature.asc
Description: OpenPGP digital signature