qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu and -vga vs. -device


From: Adam Williamson
Subject: Re: qemu and -vga vs. -device
Date: Tue, 27 Sep 2022 15:01:45 -0700
User-agent: Evolution 3.46.0 (by Flathub.org))

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.

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

It's definitely behavior I've seen other CLI tools use and it makes
sense to me.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net





reply via email to

[Prev in Thread] Current Thread [Next in Thread]