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?

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


Reply via email to