qemu: remove useless '-serial none' arg

[matttbe]

When not using the --graphics mode, or without the script options, QEmu was always launched with:

-serial none -serial chardev:console

-serial none means "don't allocate this serial device". Here, it is directly overridden by another serial. Best not to declare '-serial none' then.

Since QEmu 8.2.2, having -serial none -serial <something> is no longer supported, and it is then recommended to remove the unnecessary -serial none [1]. It continues to work on previous versions (tested on 8.2.1).

Reported-by: @tehcaster (and others)
Closes: #97
Link: https://lore.kernel.org/qemu-devel/20240122163607.459769-2-peter.maydell@linaro.org/ [1]
Suggested-by: @ishitatsuyuki

Note: I'm not using QEmu 8.2.2 yet, but a few people reported having this issue with it, and a solution has already been suggested. So why not doing the modification in the code for everyone :)

[ishitatsuyuki]

It shouldn't close the bug. I still need to replace console=hvc0 with console=ttyS0 for input to work.

[matttbe]

@ishitatsuyuki which commands are you using and with which arch?

Because on my side (x86_64 and ./vng -r -v -g --dry-run -- xeyes), it uses console=ttyS0.

EDIT: oops, not fully awake, I was using an old command with the --dry-run (with -g), I can now see console=hvc0

[ishitatsuyuki]

I use ../virtme-ng/vng -v -m 4G --cwd /tmp. The full command line below uses console=hvc0 but virtme_console=ttyS0.

/usr/bin/qemu-system-x86_64 -name virtme-ng -m 4G -fsdev local,id=virtfs5,path=/,security_model=none,readonly=on,multidevs=remap -device virtio-9p-pci,fsdev=virtfs5,mount_tag=/dev/root -machine accel=kvm:tcg -device i6300esb,id=watchdog0 -cpu host -parallel none -net none -echr 1 -chardev file,path=/proc/self/fd/2,id=dmesg -device virtio-serial-pci -device virtconsole,chardev=dmesg -chardev stdio,id=console,signal=off,mux=on -serial chardev:console -mon chardev=console -vga none -display none -smp 16 -kernel ./arch/x86/boot/bzImage -append 'virtme_hostname=virtme-ng nr_open=1073741816 virtme_link_mods=/home/ishitatsuyuki/Documents/winekvm/linux/.virtme_mods/lib/modules/0.0.0 virtme_rw_overlay0=/etc virtme_rw_overlay1=/lib virtme_rw_overlay2=/home virtme_rw_overlay3=/opt virtme_rw_overlay4=/srv virtme_rw_overlay5=/usr virtme_rw_overlay6=/var console=hvc0 earlyprintk=serial,ttyS0,115200 virtme_console=ttyS0 psmouse.proto=exps "virtme_stty_con=rows 38 cols 100 iutf8" TERM=xterm-256color virtme_chdir=tmp virtme_user=ishitatsuyuki rootfstype=9p rootflags=version=9p2000.L,trans=virtio,access=any raid=noautodetect ro init=/home/ishitatsuyuki/Documents/winekvm/virtme-ng/virtme/guest/bin/virtme-ng-init'

[arighi]

Thanks for looking at this @matttbe and @ishitatsuyuki!

Everything seems to work for me with this change (but I'm still on qemu 8.2.1).

@ishitatsuyuki the problem about using console=ttyS0 is that we won't get the stderr redirection on the host properly via the virtconsole device. Basically something like vng -vr -- uname -r 2> /tmp/kernel.log shouldn't work if we use ttyS0... so I guess we need to figure out why hvc0 doesn't work in your case.

Do you have CONFIG_HVC_DRIVER enabled in your kernel .config? I guess we need to enforce this option in virtme-configkernel...

[ishitatsuyuki]

CONFIG_HVC_DRIVER=y is in my config, yes.

[matttbe]

@ishitatsuyuki was it working before with older QEmu versions?

[ishitatsuyuki]

I'm pretty sure it was working, but I've since upgraded the kernel tree, and downgrading qemu on Arch also seems a lot of effort since there's a lot of packages.

[Byte-Lab]

Confirmed that this fixes QEMU 8.2.2 on Arch both with and without --no-virtme-ng-init.

Tested-by: David Vernet void@manifault.com

[arighi]

Alright since more people are experiencing this issue, I've decide to merge this, if there are still open issues we can fix them in tree.

Thanks tons everyone for investigating, testing and fixing this!

[ishitatsuyuki]

Sorry for the noise, the console issue was due to a version mismatch (I forgot to update the virtme-ng-init submodule). After updating it works now.

[SPYFF]

Thanks for the fix. This fix alone might worth a release, just to make sure distros tracking the stable releases fetching this quickly.

[arighi]

Thanks for the fix. This fix alone might worth a release, just to make sure distros tracking the stable releases fetching this quickly.

Agreed, I'm planning to cut a new release later today!