Thomas Huth <th...@redhat.com> writes: > On 11/07/2023 01.02, Michael S. Tsirkin wrote: >> From: Milan Zamazal <mzama...@redhat.com> >> We don't have a virtio-scmi implementation in QEMU and only support > >> a >> vhost-user backend. This is very similar to virtio-gpio and we add the same >> set of tests, just passing some vhost-user messages over the control socket. >> Signed-off-by: Milan Zamazal <mzama...@redhat.com> >> Acked-by: Thomas Huth <th...@redhat.com> >> Message-Id: <20230628100524.342666-4-mzama...@redhat.com> >> Reviewed-by: Michael S. Tsirkin <m...@redhat.com> >> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> >> --- >> tests/qtest/libqos/virtio-scmi.h | 34 ++++++ >> tests/qtest/libqos/virtio-scmi.c | 174 +++++++++++++++++++++++++++++++ >> tests/qtest/vhost-user-test.c | 44 ++++++++ >> MAINTAINERS | 1 + >> tests/qtest/libqos/meson.build | 1 + >> 5 files changed, 254 insertions(+) >> create mode 100644 tests/qtest/libqos/virtio-scmi.h >> create mode 100644 tests/qtest/libqos/virtio-scmi.c > > Hi! > > I'm seeing some random failures with this new scmi test, so far only > on non-x86 systems, e.g.: > > https://app.travis-ci.com/github/huth/qemu/jobs/606246131#L4774 > > It also reproduces on a s390x host here, but only if I run "make check > -j$(nproc)" - if I run the tests single-threaded, the qos-test passes > there. Seems like there is a race somewhere in this test?
Hmm, it's basically the same as virtio-gpio.c test, so it should be OK. Is it possible that the two tests (virtio-gpio.c & virtio-scmi.c) interfere with each other in some way? Is there possibly a way to serialize them to check? > No clue how to debug this, but since it currently only happens on > non-x86 architectures, maybe we should limit it to x86 hosts for now? > > Thomas
