Re: qemu and -vga vs. -device

[Daniel Henrique Barboza]

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.