From: "Alex Bennée" <alex.bennee@linaro.org>
To: Eric Auger <eauger@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
slp@redhat.com, mathieu.poirier@linaro.org, mst@redhat.com,
viresh.kumar@linaro.org, qemu-devel@nongnu.org,
stefanha@redhat.com, marcandre.lureau@redhat.com,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re:
Date: Thu, 14 Apr 2022 23:53:59 +0100 [thread overview]
Message-ID: <87tuavs2bb.fsf@linaro.org> (raw)
Eric Auger <eauger@redhat.com> writes:
> Hi Alex,
>
> On 4/7/22 5:00 PM, Alex Bennée wrote:
>> When trying to work out what the virtio-net-tests where doing it was
>> hard because the g_test_trap_subprocess redirects all output to
>> /dev/null. Lift this restriction by using the appropriate flags so you
>> can see something similar to what the vhost-user-blk tests show when
>> running.
>>
>> While we are at it remove the g_test_verbose() check so we always show
>> how the QEMU is run.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>> tests/qtest/qos-test.c | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/tests/qtest/qos-test.c b/tests/qtest/qos-test.c
>> index f97d0a08fd..c6c196cc95 100644
>> --- a/tests/qtest/qos-test.c
>> +++ b/tests/qtest/qos-test.c
>> @@ -89,9 +89,7 @@ static void qos_set_machines_devices_available(void)
>>
>> static void restart_qemu_or_continue(char *path)
>> {
>> - if (g_test_verbose()) {
>> - qos_printf("Run QEMU with: '%s'\n", path);
>> - }
>> + qos_printf("Run QEMU with: '%s'\n", path);
>> /* compares the current command line with the
>> * one previously executed: if they are the same,
>> * don't restart QEMU, if they differ, stop previous
>> @@ -185,7 +183,8 @@ static void run_one_test(const void *arg)
>> static void subprocess_run_one_test(const void *arg)
>> {
>> const gchar *path = arg;
>> - g_test_trap_subprocess(path, 0, 0);
>> + g_test_trap_subprocess(path, 0,
>> + G_TEST_SUBPROCESS_INHERIT_STDOUT | G_TEST_SUBPROCESS_INHERIT_STDERR);
> While workling on libqos/pci tests on aarch64 I also did that but I
> noticed there were a bunch of errors such as:
>
> /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-net-pci/virtio-net/virtio-net-tests/vhost-user/multiqueue:
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid
> argument (22)
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid
> argument (22)
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 2 ring restore failed: -22: Invalid
> argument (22)
> qemu-system-aarch64: Failed to set msg fds.
> qemu-system-aarch64: vhost VQ 3 ring restore failed: -22: Invalid
> argument (22)
>
> I see those also when running with x86_64-softmmu/qemu-system-x86_64
> (this is no aarch64 specific).
I think this is a symptom of an unclean tear down (which might be too
much to ask for our fake vhost backend) or something we should handle
better. I still have to get my gpio test working so I'll have a look
tomorrow.
>
> I don't know if it is an issue to get those additional errors?
>
> Thanks
>
> Eric
>
>> g_test_trap_assert_passed();
>> }
>>
>>
--
Alex Bennée
next reply other threads:[~2022-04-14 22:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 22:53 Alex Bennée [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-07-15 21:06 Phil Dennis-Jordan
2024-07-16 6:07 ` Akihiko Odaki
2024-07-17 11:16 ` Re: Phil Dennis-Jordan
2022-04-17 17:43 [PATCH v3 00/60] target/arm: Cleanups, new features, new cpus Richard Henderson
2022-04-17 17:43 ` [PATCH v3 06/60] target/arm: Change CPUArchState.aarch64 to bool Richard Henderson
2022-04-19 11:17 ` Alex Bennée
2020-10-08 18:30 罗勇刚(Yonggang Luo)
2020-10-08 19:24 ` Paolo Bonzini
2020-10-08 20:16 ` Re: 罗勇刚(Yonggang Luo)
2020-02-20 5:40 Wayne Li
2020-02-20 9:57 ` Peter Maydell
2020-02-20 16:52 ` Re: Wayne Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tuavs2bb.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=eauger@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mathieu.poirier@linaro.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).