Hi David,
On 15/07/2026 19:12, David Matlack wrote:
On Wed, Jul 15, 2026 at 10:47 AM Matt Evans matt@ozlabs.org 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...
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