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

[Alex Williamson]

On Tue, 31 Mar 2026 10:29:31 +0200
Niklas Schnelle <schnelle@xxxxxxxxxxxxx> wrote:

> On Mon, 2026-03-30 at 21:03 -0300, Jason Gunthorpe wrote:
> > On Mon, Mar 30, 2026 at 12:39:25PM -0600, Alex Williamson wrote:  
> > > Yes, that would be the ideal balance of enabling larger BARs while
> > > retaining compatibility for existing devices.  Sounds like we'll
> > > continue down the variant driver path for this one-off device for
> > > now.  It remains fairly self contained so long as we don't add more
> > > regions for vfio-pci-core to manage.
> > > 
> > > This could be a good project if someone is looking though, especially
> > > if it had a build-time config option to set the minimum region size so
> > > we can exercise it before we hit 1TB BARs.  Thanks,  
> > 
> > Well, it took claude an hour to vibe code a draft from a four sentence
> > prompt.. I see many things that need changing/cleaning in here, but
> > the patch strategy and general idea looks sound.
> > 
> > I guess another day of effort would probably get things into something
> > presentable. We are not so far away - maybe the variant driver path is
> > not necessary?
> > 
> > https://github.com/jgunthorpe/linux/commits/vfio_maple_tree/
> > 
> > Jason  
> 
> I'm in no way against changing the offset handling in general but for
> what it's worth, we need a variant driver for ISM regardless, though it
> would be smaller with large offset support. This is because besides the
> large BAR we also have to use our classic function handle based PCI
> instructions to access that BAR instead of the newer memory-I/O (MIO)
> PCI instructions. And sadly the way the ISM device uses the PCI Store
> Block instruction there is no straight forward way to enable the newer
> instructions even if we changed the device implementation. This also
> means that we would want to keep the no-mmap() restriction.

It feels a bit late in the cycle for an untested maple tree conversion
anyway, though I am interested in it for v7.2.  So I think we're agreed
in the variant driver here to handle the excessively large BAR with no
currently foreseeable need for additional regions, and maybe it gets
simplified when that conversion occurs later.  Thanks,

Alex