Re: [PATCH v8 2/3] vfio/ism: Implement vfio_pci driver for ISM devices

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Mar 30, 2026 at 12:09:45PM -0600, Alex Williamson wrote:
> On Mon, 30 Mar 2026 12:56:51 -0300
> Jason Gunthorpe <jgg@ziepe.ca> wrote:
> 
> > On Mon, Mar 30, 2026 at 09:36:46AM -0600, Alex Williamson wrote:
> > > There's risk involved with changing the default shift.  The fear is
> > > there's userspace drivers that hard code the shift.  DPDK was even such
> > > a user at one point, iirc.  Maybe it's ok to break such users, maybe
> > > there are actually no such users left and it's all FUD at this point.
> > > Either way, I have a hard time justifying that risk for a single,
> > > obscure S390 device.  
> > 
> > If we go ahead with that DMABUF series could obscure cases like this
> > be told to just get a DMABUF FD and then mmap it? Avoid this whole
> > issue?
> 
> The ISM device here doesn't support mmap, so that much is still a
> problem.  However, if we imagine a future where we've fully converted
> to dma-buf for both DMA and CPU access to BARs, then maybe...  I don't
> know how we'd describe a region overflow in the "legacy" ioctls to
> maintain some consistency between what's exposed through the region
> versus the dma-buf.  Thanks,

Oh, Ok.. I go back to what I've said before many times, if we fix this
we should fix it by making the region offset fully dynamic and managed
by a maple tree.

We can detect at runtime when the vfio device is created if it is
compatible with the legacy indexs and use them by default to maintain
compatibility. But cases like this where the region is just too big
(and GPUs will get there soon too!) can run a full dynamic mode.

Jason