Re: qemu and -vga vs. -device

[Daniel Henrique Barboza <danielhb413@gmail.com>]

On 9/27/22 19:01, Adam Williamson wrote:
> On Tue, 2022-09-27 at 13:34 -0300, Daniel Henrique Barboza wrote:
>> Hi Adam,
>>
>> On 9/26/22 06:26, Gerd Hoffmann wrote:
>>> On Sat, Sep 24, 2022 at 12:12:45AM -0700, Adam Williamson wrote:
>>>> On Mon, 2022-09-19 at 06:42 +0200, Gerd Hoffmann wrote:
>>>>> On Fri, Sep 16, 2022 at 10:02:17AM -0700, Adam Williamson wrote:
>>>>>> Hi Gerd!
>>>>>>
>>>>>> I'm working on a patch to revise how openQA sets video devices in qemu.
>>>>>> In that context, a question: if we always want to specify a single
>>>>>> video device with `-device` (e.g. `-device VGA` or `-device virtio-
>>>>>> vga`), should we also specify `-vga none` to ensure qemu doesn't also
>>>>>> include another adapter as a default for the -vga arg?
>>>>>
>>>>> Doesn't hurt to include it.  In theory it should not be needed, qemu has
>>>>> a list of vga devices and in case '-device $vga' is found on the command
>>>>> line will turn off the default vga device automatically.  In practice
>>>>> there are qemu versions where this list is not complete, so it
>>>>> sometimes doesn't work as intended.
>>>>>
>>>>> Alternatively use '-nodefaults' which will disable all automatically
>>>>> added devices (vga, nic, cdrom, ...).
>>>>
>>>> Thanks Gerd!
>>>>
>>>> So, I got around to testing this today, and found something
>>>> interesting. On ppc64le, adding `-vga none` seems to break things.
>>>> Booting a Fedora installer ISO, which should show the boot menu with a
>>>> 60 second timeout then boot to the installer, if we run the VM with `-
>>>> vga std`, we see the bootloader. If we run it with `-device VGA` and no
>>>> `-vga` arg, we see the bootloader. But if we run qemu with `-vga none -
>>>> device VGA`, we don't see the bootloader. The system just sits at the
>>>> OFW init screen apparently forever (I thought it might actually be
>>>> running in the background and recover to anaconda after the 60 second
>>>> boot timeout, but it doesn't seem to).
>>>>
>>>> Not sure what's going on there, but thought you might be interested.
>>
>> Can you please send the full command line you're using?
> 
> Hi Daniel! Here it is:
> 
> /usr/bin/qemu-system-ppc64 -vga none -device VGA,edid=on,xres=1024,yres=768 -g 1024x768 -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.fdtypeA=none -m 4096 -machine usb=off,cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken,cap-ccf-assist=off -cpu host -netdev user,id=qanet0,net=172.16.2.0/24 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -boot once=d -device nec-usb-xhci -device usb-tablet -device usb-kbd -smp 1 -enable-kvm -no-shutdown -vnc :99,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev pipe,id=virtio_console1,path=virtio_console1,logfile=virtio_console1.log,logappend=on -device virtconsole,chardev=virtio_console1,name=org.openqa.console.virtio_console1 -chardev socket,path=qmp_socket,server=on,wait=off,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-file,filename=/var/lib/openqa/pool/9/raid/hd0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on,discard=unmap -device virtio-blk,id=hd0-device,drive=hd0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/var/lib/openqa/pool/9/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on,discard=unmap -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0
> 
> the version without `-vga none` would be literally exactly the same but
> without that one option.

I'll try it out later and see what happens.

> 
> Note, it looks like I was just a bit impatient in my manual trials;
> looking at some jobs that ran today, they did eventually clear to the
> Fedora installer GUI after about 90-120 seconds. But they definitely
> don't show the bootloader (which our test system expects to see, so the
> test fails). When run without the `-vga none` part, the bootloader is
> shown at the same resolution and using the same fonts as the OFW
> interface.


By "bootloader" you mean grub, correct?

>>
>> I'm actually surprised that you can combo '-vga none -display VGA' together
>> in the command line is executed without a parse error.
> 
> I found various past mailing list discussions suggesting this is a good
> idea just to ensure qemu doesn't add the 'default' device (so far as
> the `-vga` arg is concerned) to the specified video device. Gerd didn't
> see any problem with doing it when I asked him, either.
>>
>> This also works, which is also surprising to me:
>>
>>
>> (launches the process with the 'curses' display)
>> ./qemu-system-ppc64 -M pseries -display none -display curses
>>
>>
>> (launches with the 'none' display)
>> ./qemu-system-ppc64 -M pseries -display curses -display none
>>
>>
>> It seems that we're considering just the last entry as valid.
>>
>> Should I send a patch to make QEMU error out when multiple '-display'
>> options are present in the command line?
> 
> The behaviour you describe there is probably what I expect, or at least
> prefer. That's how I'd design it if I had to choose. The advantage of
> this "when multiple specifications given for an arg that can take only
> one, use the last one given" behaviour is it allows for overriding. Say
> you have a tool that usually runs "qemu -vga std" but wants to allow
> the user to override it; it's much easier to implement that if qemu
> takes the last-specified entry, because you can just dump the "user
> overriden" args at the end, and be confident that they'll "win". If
> qemu doesn't do that but errors out, your tool has to carefully remove
> its "default" specifications for any arg that the user wanted to
> override.

Makes sense. Guess we're better off leaving this alone.

I still find this a weird, although the shorter command line I used aggravated
the weirdness. With the huge command line you sent above, yes, it's waaay better
to just insert -display none at the end instead of reading the whole thing and
see if there's another ´-display' option in the middle.


Thanks,

Daniel

> 
> It's definitely behavior I've seen other CLI tools use and it makes
> sense to me.