On Mon, May 26, 2025 at 10:09 AM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > 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 Thanks for sharing, I've started to take a look. Joel, please take a look at this series too and let me know your thoughts. > > 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. How broad do you think the reusability should go? I structured the library (which includes the driver framework and drivers) so that it is reusable across other selftests (i.e. not just in tools/testing/selftests/vfio). The last 3 patches in this series show it being used in KVM selftests for example. IOMMU-focused tests in tools/testing/selftests/iommu could also use it. But it's not reusable outside of selftests, or outside of the kernel source tree. My intuition is the former wouldn't be too hard to support, but the latter would be challenging. > > > 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. I was also thinking of using NVMe for this (cheap, broadly available), but I'm a little worried someone might accidentally corrupt their boot disk if they accidentally pass in the wrong BDF :) Do you think mlx5 HW could support the current driver API?
