Re: [Qemu-devel] [PATCH v2] util: check the return value of fcntl in qemu_set_{block, nonblock}

[Peter Maydell]

On Fri, 14 Dec 2018 at 09:16, Li Qiang <address@hidden> wrote:
> First of all I want to know does the following error means?
> doesn't it mean "the x86 qtest is ok and aarch64 is not ok"?
>
>
>   GTESTER check-qtest-x86_64
>   GTESTER check-qtest-aarch64
> vhost-user-test: /tmp/qemu-test/src/util/oslib-posix.c:245: 
> qemu_set_nonblock: Assertion `f != -1' failed.
> Broken pipe
> GTester: last random seed: R02S61a1e35369394d7efb0a0e96d8af615d
>   GTESTER tests/test-qht-par
> vhost-user-test: /tmp/qemu-test/src/util/oslib-posix.c:245: 
> qemu_set_nonblock: Assertion `f != -1' failed.
> Broken pipe
> GTester: last random seed: R02Sbf8c21ef5f216840e073ff3e487dedbc
> vhost-user-test: /tmp/qemu-test/src/util/oslib-posix.c:245: 
> qemu_set_nonblock: Assertion `f != -1' failed.
> Broken pipe
> GTester: last random seed: R02Sfe8cd276fddf3a92891cf274bf88e888
> vhost-user-test: /tmp/qemu-test/src/util/oslib-posix.c:245: 
> qemu_set_nonblock: Assertion `f != -1' failed.
> Broken pipe
> GTester: last random seed: R02S7487fc065e22541ba4c78c0db6c61d3c
> Could not access KVM kernel module: No such file or directory

I think maybe the make output is confusing you here, because it's
running both qtests in parallel. We don't ever run the
vhost-user-test for arm guests: tests/Makefile adds it only
to check-qtest-i386 and check-qtest-x86_64. So I think all
the warnings/errors here are coming from the x86 test.

> the 'ioeventfd_enabled()' returns 0 and 'kvm_eventfds_allowed' is 0 which 
> means the
> kernel doesn't support eventfd.

> After I look at the kernel, the arm platform seems doesn't support eventfd.
>
> So if my understanding is correct in the first, '"the x86 qtest is ok and 
> aarch64 is not ok".
> This can be explainable. But if not, there maybe another issue.

It looks to me from the investigation you did that the
vhost-user-test is assuming that we are using KVM
and ioeventfds, and is misbehaving when that is not true.
We should fix the test so that either it works in that
configuration, or correctly skips doing the test if it
is not applicable in a different config.

thanks
-- PMM