Hi David, On 15/07/2026 19:12, David Matlack wrote: > On Wed, Jul 15, 2026 at 10:47 AM Matt Evans <[email protected]> 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
