On 5/20/25 10:24 AM, Stefano Garzarella wrote:

On Thu, May 15, 2025 at 03:00:48PM -0700, Bobby Eshleman wrote:

quoted

This commit introduces a new vmtest.sh runner for vsock.

It uses virtme-ng/qemu to run tests in a VM. The tests validate G2H,
H2G, and loopback. The testing tools from tools/testing/vsock/ are
reused. Currently, only vsock_test is used.

VMCI and hyperv support is automatically built, though not used.

Only tested on x86.

To run:

 $ make -C tools/testing/selftests TARGETS=vsock
 $ tools/testing/selftests/vsock/vmtest.sh

I am a little confused, now we have removed the kernel build step, so 
how should I test this? (It's running my fedora kernel, but then ssh 
fails to connect)

Would it be better to re-introduce the build phase at least in the 
script as optional (not used by selftest, but usable if you want to use 
the script directly)?

Or at least I think we should explain that the script launches the 
running kernel, because the config file introduced by this patch 
confused me. How it's supposed to be used?

This is the usual selftests schema. The user has to build and install
the kernel including the specified config before running the tests, see

make help |grep kselftest

Also this is what we do for our CI:

https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-style

@Bobby: AFAICS this now has all the ingredients to fit NIPA integration
am I correct? the last commit message sentence could possibly be dropped.

Still it could be worthy to re-introduce (behind a command line option)
the ability to build the kernel as per Stefano request, to fit his
existing workflow (sorry for the partial back and forth).

Thanks,

Paolo