Re: [PATCH v5 0/9] vfio/pci: Add mmap() for DMABUFs

[Matt Evans]

Hi David,

On 15/07/2026 19:12, David Matlack wrote:
> On Wed, Jul 15, 2026 at 10:47 AM Matt Evans <matt@xxxxxxxxxx> wrote:
> 
>> This is based on v7.2-rc3.
>>
>> These commits are on GitHub for easier browsing, along with
>> "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test":
>>
>> https://github.com/metamev/linux/compare/v7.2-rc3...dev/mev/vfio-dmabuf-mmap-v5
> 
> It'd be great to have this test upstream. I'm happy to review it when
> you're ready. Looks like it just needs to be redone to use the VFIO
> selftests library and kselftests harness. AI could probably do the
> conversion pretty quick :)

For sure, I'd intended to catch up with you on best approach here. :)

Aside from the organic structure of the test (the open-coded VFIO
device/group setup/init needs to go), the main issue is that it relies
on a hacked/out of tree QEMU "EDU++" device with a second larger BAR
(containing freely read-writable memory).  A subset of tests run with
the in-tree EDU device, but coverage is too low.

The desirable properties are:

 - Having a BAR that is pure memory (all locations present, writable
without disruptive side-effects) so that mapping aliases can be
constructed and detected.  This is good to test things like non-zero
vm_pgoffs and VA space presentation of physically-discontiguous DMABUFs.

 - BAR >> hugepage size so we can eyeball huge mappings work (or better,
 mechanically test for them).  At least 32MB would tick this box for 4K,
16K page systems.

 - Something QEMU supports*, so one can run the test in a VM/TCG system.

There were some real device models in QEMU that could be used this way,
but needed a fair bit of setup;  I didn't want to rathole
vfio_dmabuf_mmap_test on including a ton of device-specific code for
some video card or similar.

I'll dig more for a simple target that provides these properties --
obviously it would be better to point this test at an off-the-shelf
device (including silicon!).  And, proposing EDU extensions to the QEMU
folks may be useful (there're uses for a better EDU in other contexts too).

Since this test uses MMIO for a specific [class of] function, my first
thought is it should be another VFIO driver-type test sibling of
vfio_pci_driver_test.  For example, we could extend the driver-type
tests' backend struct vfio_pci_driver_ops for functions capable of
providing a Big Memory BAR, like QEMU EDU++.  EDU can also memcpy, so
could also support vfio_pci_driver_test.

The spirit of the device backends hiding setup of a complex device is
handy, and it's plausible that several backends could provide this "big
memory BAR" service.  What do you think, any concerns with extending
vfio_pci_driver_ops like that?


Thanks,


Matt