Re: [PATCH v4 0/3] vfio/pci: Introduce vfio_pci driver for ISM devices

[Niklas Schnelle]

On Mon, 2026-03-16 at 13:03 -0600, Alex Williamson wrote:
> On Mon, 16 Mar 2026 13:33:04 +0100
> "Julian Ruess" <julianr@xxxxxxxxxxxxx> wrote:
> 
> > On Fri Mar 13, 2026 at 4:41 PM CET, Alex Williamson wrote:
> > > On Fri, 13 Mar 2026 15:40:27 +0100
> > > Julian Ruess <julianr@xxxxxxxxxxxxx> wrote:
> > >  
--- snip ---
> > 
> > Hi Alex,
> > 
> > thanks for the quick feedback!
> > 
> > We are currently developing this extension for a non‑QEMU vfio user space
> > driver. Reads smaller than 8 bytes are theoretically valid, but they are not
> > used by this driver nor the existing in-kernel driver at the moment. We could
> > extend this in the future if needed.
> > 
> > vfio‑pci based PCI pass-through of the ISM device is already possible without
> > this extension. In that case, the ISM driver in the guest kernel accesses the
> > BARs directly through hardware virtualization, without using the new access
> > routines provided by this variant driver.
> 
> Hi Julian,
> 
> The cover letter argues a secondary use case with QEMU, especially in a
> nested environment.  The ISM range appears to be an interface to a
> variety of device types, console and block are noted.  It's also noted
> in the implementation that the z/Architecture allows sub-8-byte access.
> 
> I think we need to be cautious that the existence of this driver makes
> it available for use with QEMU and other VMMs.  In the case of QEMU
> vfio_region_ops will allow single-byte access by default.
> 
> The restricted access width is positioned as a simplification here, but
> it needs to be evaluated against all the use cases.  Unless we're 100%
> sure none of those use cases rely on sub-8-byte accesses, we might be
> setting ourselves up for hacks later to fix or detect partial access
> support.
> 
> I'll leave it to IBM folks to determine if this is indeed a
> simplification for long term support of all use cases and not a short
> term fix for the short term use case.  Thanks,
> 
> Alex

Hi Alex,

Thank you for the insights and expertise it is highly appreciated. Your
reasoning makes sense to me and I agree this simplification looks like
it may be ok for now but could cause more trouble than it is worth
later and there's really no reason not to just support < 8 byte
accesses too.

One thing I'd like to explain though since you mention ISM potentially
being an interface to different device types. This part of the cover
letter is easy to misunderstand since we haven't yet send out patches
opening up that direction. There is only one ISM device and even future
versions would likely just iterate but serve the same purpose. The
multiple device types including consoles and block devices will not
replace this ISM device but rather sit on top of a virtual bus called
the ISM Peer Bus where the ISM device will serve as a communication
channel between two Linux instances connected via an ISM device.
Specifically in the current design there will be a vfio-pci based user-
space daemon/driver on one Linux instance that provides virtual
consoles and block devices for other Linux instances on the other side
of ISM based communication channels. Those Linux instances will use
kernel integrated drivers for the console and block devices. Currently
there are no plans for passing these devices through to guests since we
can also just pass-through an ISM device and ISM devices being virtual
we're not limited in how many we can have.

Thanks,
Niklas