Re: [RFC PATCH 00/33] vfio: Introduce selftests for VFIO

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, May 23, 2025 at 11:29:45PM +0000, David Matlack wrote:
> Drivers must implement the following methods:
> 
>  - probe():        Check if the driver supports a given device.
>  - init():         Initialize the driver.
>  - remove():       Deinitialize the driver and reset the device.
>  - memcpy_start(): Kick off a series of repeated memcpys (DMA reads and
>                    DMA writes).
>  - memcpy_wait():  Wait for a memcpy operation to complete.
>  - send_msi():     Make the device send an MSI interrupt.
> 
> memcpy_start/wait() are for generating DMA. We separate the operation
> into 2 steps so that tests can trigger a long-running DMA operation. We
> expect to use this to stress test Live Updates by kicking off a
> long-running mempcy operation and then performing a Live Update. These
> methods are required to not generate any interrupts.

I like this, it is a smart way to go about building a testing
framework.

Joel had sent something that looks related:

https://lore.kernel.org/r/5zoh5r6eovbpijic22htkqik6mvyfbma5w7kjzcpz7kgbjufd2@yw6ymwy2a54s

IMHO it would be very nice to lean into what Joel was thinking of a
'libvfn' where the above device stuff is inside a library and it can
be re-used for other purposes.

We keep running into scenarios where it would be really nice to be
able to do DMA testing and we just don't have easy ways to build SW to
do that.

A reusable mini-driver framework that can trigger DMA is a huge leap
forward.

> Library:
> 
>  - Driver support for devices that can be used on AMD, ARM, and other
>    platforms.

I would be very happy to see a mlx5 driver option. mlx5 class HW is
widely available, cheap on ebay, and it would make this usable by
pretty much anyone who wants.

Jason