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/20171213023131.41233-1-aik@ozlabs.ru/
Only nvgrace-gpu and some i915 reference SPARSE_MMAP today.