From: Alex Williamson <alex@shazbot.org>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
Farhan Ali <alifm@linux.ibm.com>,
Julian Ruess <julianr@linux.ibm.com>,
wintera@linux.ibm.com, ts@linux.ibm.com, oberpar@linux.ibm.com,
gbayer@linux.ibm.com, Yishai Hadas <yishaih@nvidia.com>,
Shameer Kolothum <skolothumtho@nvidia.com>,
Kevin Tian <kevin.tian@intel.com>,
mjrosato@linux.ibm.com, raspl@linux.ibm.com, hca@linux.ibm.com,
agordeev@linux.ibm.com, gor@linux.ibm.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
linux-pci@vger.kernel.org, alex@shazbot.org
Subject: Re: [PATCH v8 2/3] vfio/ism: Implement vfio_pci driver for ISM devices
Date: Mon, 30 Mar 2026 12:39:25 -0600 [thread overview]
Message-ID: <20260330123925.713edac4@shazbot.org> (raw)
In-Reply-To: <20260330181645.GE246076@ziepe.ca>
On Mon, 30 Mar 2026 15:16:45 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:
> 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.
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,
Alex
next prev parent reply other threads:[~2026-03-30 18:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 13:31 [PATCH v8 0/3] vfio/pci: Introduce vfio_pci driver for ISM devices Julian Ruess
2026-03-25 13:31 ` [PATCH v8 1/3] vfio/pci: Rename vfio_config_do_rw() to vfio_pci_config_rw_single() and export it Julian Ruess
2026-03-25 13:31 ` [PATCH v8 2/3] vfio/ism: Implement vfio_pci driver for ISM devices Julian Ruess
2026-03-26 13:03 ` Niklas Schnelle
2026-03-26 19:05 ` Farhan Ali
2026-03-27 14:53 ` Niklas Schnelle
2026-03-30 15:36 ` Alex Williamson
2026-03-30 15:56 ` Jason Gunthorpe
2026-03-30 18:09 ` Alex Williamson
2026-03-30 18:16 ` Jason Gunthorpe
2026-03-30 18:39 ` Alex Williamson [this message]
2026-03-31 0:03 ` Jason Gunthorpe
2026-03-31 8:29 ` Niklas Schnelle
2026-03-31 20:44 ` Alex Williamson
2026-03-30 18:15 ` Niklas Schnelle
2026-04-01 16:28 ` Farhan Ali
2026-04-01 22:04 ` Alex Williamson
2026-04-02 9:06 ` Julian Ruess
2026-03-25 13:31 ` [PATCH v8 3/3] MAINTAINERS: add VFIO ISM PCI DRIVER section Julian Ruess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260330123925.713edac4@shazbot.org \
--to=alex@shazbot.org \
--cc=agordeev@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=gbayer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jgg@ziepe.ca \
--cc=julianr@linux.ibm.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=raspl@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=skolothumtho@nvidia.com \
--cc=ts@linux.ibm.com \
--cc=wintera@linux.ibm.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox