[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] libqtest: refuse QTEST_QEMU_BINARY=qemu-kvm

From: Thomas Huth
Subject: Re: [PATCH v2] libqtest: refuse QTEST_QEMU_BINARY=qemu-kvm
Date: Mon, 12 Apr 2021 11:35:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

On 12/04/2021 11.18, Stefan Hajnoczi wrote:
Some downstreams rename the QEMU binary to "qemu-kvm". This breaks
qtest_get_arch(), which attempts to parse the target architecture from
the QTEST_QEMU_BINARY environment variable.

Print an error instead of returning the architecture "kvm". Things fail
in weird ways when the architecture string is bogus.

Arguably qtests should always be run in a build directory instead of
against an installed QEMU. In any case, printing a clear error when this
happens is helpful.

Reported-by: Qin Wang <qinwang@rehdat.com>
Cc: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
  tests/qtest/libqtest.c | 10 ++++++++++
  1 file changed, 10 insertions(+)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index 71e359efcd..7caf20f56b 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -910,6 +910,16 @@ const char *qtest_get_arch(void)
+ if (!strstr(qemu, "-system-")) {
+        fprintf(stderr, "QTEST_QEMU_BINARY must end with *-system-<arch> where 
+                        "'arch' is the target architecture (x86_64, aarch64, "
+                        "etc). If you are using qemu-kvm or another custom "
+                        "name, please create a symlink like ln -s "
+                        "path/to/qemu-kvm qemu-system-x86_64 and use that "
+                        "instead.\n");

The text is very long ... maybe add some \n to wrap it after 80 columns?
(also not sure whether we really need the second part about the symlink... but I also don't mind leaving it in)

+        abort();

Since this can be triggered by the user, I'd rather use exit(1) instead, what do you think?


+    }
      return end + 1;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]