On Thu, Jan 08, 2026 at 08:25:19AM -0800, Alex Mastro wrote:
> On Thu, Jan 08, 2026 at 10:38:04AM -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 07, 2026 at 07:36:44PM -0800, Alex Mastro wrote:
> > > The intent of QEMU's mmap alignment code is imperfect in the SPARE_MMAP
> > > case?
> > > After a hole, the next mmap'able range could be some arbitrary
> > > page-aligned
> > > offset into the region. It's not helpful mmap some region offset which is
> > > maximally 4K-aligned at a 1G-aligned vaddr.
> > >
> > > I think to be optimal, QEMU should be attempting to align the vaddr for
> > > bar
> > > mmaps such that
> > >
> > > vaddr % {2M,1G} == region_offset % {2M,1G}
> > >
> > > Would love someone to sanity check me on this. Kind of a diversion.
> >
> > What you write is correct. Ankit recently discovered this bug in
> > qemu. It happens not just with SPARSE_MMAP but also when mmmaping
> > around the MSI-X hole..
>
> Is my mental model broken? I thought MSI-X holes in a VFIO-exposed BAR region
> implied SPARSE_MMAP? I didn't think there was another way for the uapi to
> express hole-yness.
Yes, it was broken. Creating MSI-X table holes with SPARSE_MMAP ended back
in 2017 and was superseded by VFIO_REGION_INFO_CAP_MSIX_MAPPABLE [1].
[1] https://lore.kernel.org/all/[email protected]/
Only nvgrace-gpu and some i915 reference SPARSE_MMAP today.
