On 19/12/2024 09.49, David Woodhouse wrote:
On 19 December 2024 09:35:13 CET, Thomas Huth <[email protected]> wrote:
On 18/12/2024 23.14, David Woodhouse wrote:
On Wed, 2024-12-18 at 16:54 +0100, Thomas Huth wrote:
On 18/12/2024 12.48, David Woodhouse wrote:
On 18 December 2024 12:32:49 CET, Thomas Huth <[email protected]> wrote:
Use the serial console to execute the commands in the guest instead
of using ssh since we don't have ssh support in the functional
framework yet.
Signed-off-by: Thomas Huth <[email protected]>
Hm, but serial is lossy and experience shows that it leads to flaky tests if
the guest (or host) misses bytes. While SSH would just go slower.
I now noticed some issue with the serial console in this test, too.
Looks like the "Starting dropbear sshd: OK" is not print in an atomic way by
the guest, sometimes there are other kernel messages between the ":" and the
"OK". It works reliable when removing the "OK" from the string.
Nah, that still isn't atomic; you just got lucky because the race
window is smaller. It's not like serial ports are at a premium; can't
you have a separate port for kernel vs. userspace messages?
Maybe easiest solution: Simply add "quiet" to the kernel command line, then it
does not write the kernel messages to the serial console anymore.
Want to resend the bug report about that test failing again? But without the
kernel messages this time... :)
With "quiet", the output just looks like this when it hangs:
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
Spectre V2 : Kernel not compiled with retpoline; no mitigation available!
kvm_intel: VMX not supported by CPU 0
Cannot get hvm parameter CONSOLE_EVTCHN (18): -22!
fail to initialize ptp_kvm
Anyway, to properly track this, I've now created a ticket with the full log:
https://gitlab.com/qemu-project/qemu/-/issues/2731
Thomas
