On Thu, Jul 11, 2024 at 07:14:55AM GMT, Jakub Kicinski wrote:
On Thu, 11 Jul 2024 15:38:01 +0200 Stefan Hajnoczi wrote:
> Usually vsock tests test both the driver (virtio-vsock) in the guest and the
> device in the host kernel (vhost-vsock). So I usually run the tests in 2
> nested VMs to test the latest changes for both the guest and the host.
>
> I don't know enough selftests, but do you think it is possible to integrate
> them?
>
> CCing Stefan who is the original author and may remember more reasons about
> this choice.
It's probably because of the manual steps in tools/testing/vsock/README:
The following prerequisite steps are not automated and must be performed prior
to running tests:
1. Build the kernel, make headers_install, and build these tests.
2. Install the kernel and tests on the host.
3. Install the kernel and tests inside the guest.
4. Boot the guest and ensure that the AF_VSOCK transport is enabled.
If you want to automate this for QEMU, VMware, and Hyper-V that would be
great. It relies on having a guest running under these hypervisors and
that's not trivial to automate (plus it involves proprietary software
for VMware and Hyper-V that may not be available without additional
license agreements and/or payment).
Not sure if there's a requirement that full process is automated.
Or at least if there is we are already breaking it in networking
because for some tests we need user to export some env variables
to point the test to the right interfaces and even a remote machine
to generate traffic. If the env isn't set up tests return 4 (SKIP).
I don't feel strongly that ksft + env approach is better but at
least it gives us easy access to the basic build and packaging
features from ksft. Up to you but thought I'd ask.
Yeah, I'll try to allocate some cycles to look into that. Tracking it
here: https://gitlab.com/vsock/vsock/-/issues/13
What about this patch, can we queue it for now?
Thanks,
Stefano
