linux-kernel - Re: [PATCH] test/vsock: add install target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3cx46c62lttslofdaneqqmsrcffeeblgy3d7eumuwx6x72xqtm@uux54tnn5fe7>
Date: Fri, 12 Jul 2024 10:53:39 +0200
From: Stefano Garzarella <sgarzare@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Stefan Hajnoczi <stefanha@...hat.com>, Peng Fan <peng.fan@....com>, 
	"Peng Fan (OSS)" <peng.fan@....nxp.com>, 
	"virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] test/vsock: add install target

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