Re: [RFC PATCH 2/3] vfio: mmap sparse regions backed by multiple FDs
John Levon <[email protected]>
| Newsgroups | org.nongnu.qemu-devel |
|---|---|
| Message-ID | <an9yM6aSsFaCHokk@lent> |
On Fri, Aug 14, 2026 at 12:48:30PM -0700, Naman Gulati wrote: > > Given that you've introduced a dependency on VFIORegion in the > > include/hw/vfio/vfio-device.h for the other callback, I'm wondering why we don't > > just store an array of VFIORegions in VFIODevice instead of reginfo+region_fds ? > > I tried to maintain the idiom that the VFIORegion region is synonymous > with one single BAR region. As before each VFIORegion has multiple > mmap areas underneath, the fd for each is now held in the region_fds > list. Sure, I didn't mean to imply otherwise. i.e. each individual region - whatever the type is - would have region info plus some number of fds. > > I'm also not sure why we have a sparse mmaps callback - why can't that be > > generic code that handles both capabilities? Are you concerned about the cap > > number clashing in future vfio kernel versions perhaps? > > Yes I wanted to encapsulate vfio-user specific handling within the > vfio-user logic so that it doesn't conflict with the pure vfio device > handling. It felt odd to me to introduce generic handling of a > capability that's only exposed by one flavor of device and not the > other. However, no strong opinions, I can refactor and generalize the > cap handling if that's preferred, and the risks of cap number clashes > are okay. I can see the argument either way. regards john