> On Dec 13, 2017, at 3:49 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > The vsock_diag.ko module already has a test suite but the core AF_VSOCK > functionality has no tests. This patch series adds several test cases that > exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, > half-closed connections, simultaneous connections). > > The test suite is modest but I hope to cover additional cases in the future. > My goal is to have a shared test suite so VMCI, Hyper-V, and KVM can ensure > that our transports behave the same. > > I have tested virtio-vsock. > > Jorgen: Please test the VMCI transport and let me know if anything needs to be > adjusted. See tools/testing/vsock/README for information on how to run the > test suite. >
I tried running the vsock_test on VMCI, and all the tests failed in one way or another: 1) connection reset test: when the guest tries to connect to the host, we get EINVAL as the error instead of ECONNRESET. I’ll fix that. 2) client close and server close tests: On the host side, VMCI doesn’t support reading data from a socket that has been closed by the guest. When the guest closes a connection, all data is gone, and we return EOF on the host side. So the tests that try to read data after close, should not attempt that on VMCI host side. I got the tests to pass by adding a getsockname call to determine if the local CID was the host CID, and then skip the read attempt in that case. We could add a vmci flag, that would enable this behavior. 3) send_byte(fd, -EPIPE): for the VMCI transport, the close isn’t necessarily visible immediately on the peer. So in most cases, these send operations would complete with success. I was running these tests using nested virtualization, so I suspect that the problem is more likely to occur here, but I had to add a sleep to be sure to get the EPIPE error. 4) server close test: the connect would sometimes fail. This looks like an issue where we detect the peer close on the client side before we complete the connection handshake on the client side. There are two different channels used for the connection handshake and the disconnect. I’ll look into this to see what exactly is going on. 5) multiple connections tests: with the standard socket sizes, VMCI is only able to support about 100 concurrent stream connections so this test passes with MULTICONN_NFDS set to 100. Thanks, Jorgen