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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.