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