All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex@shazbot.org>
To: "Julian Ruess" <julianr@linux.ibm.com>
Cc: <schnelle@linux.ibm.com>, <wintera@linux.ibm.com>,
	<ts@linux.ibm.com>, <oberpar@linux.ibm.com>,
	<gbayer@linux.ibm.com>, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Yishai Hadas" <yishaih@nvidia.com>,
	"Shameer Kolothum" <skolothumtho@nvidia.com>,
	"Kevin Tian" <kevin.tian@intel.com>, <mjrosato@linux.ibm.com>,
	<alifm@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 v4 0/3] vfio/pci: Introduce vfio_pci driver for ISM devices
Date: Mon, 16 Mar 2026 13:03:05 -0600	[thread overview]
Message-ID: <20260316130305.21e015ef@shazbot.org> (raw)
In-Reply-To: <DH47JTI4L8PJ.2A4XCC5SRV0NW@linux.ibm.com>

On Mon, 16 Mar 2026 13:33:04 +0100
"Julian Ruess" <julianr@linux.ibm.com> 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@linux.ibm.com> wrote:
> >  
> >> Hi all,
> >> 
> >> This series adds a vfio_pci variant driver for the s390-specific
> >> Internal Shared Memory (ISM) devices used for inter-VM communication
> >> including SMC-D.
> >> 
> >> This is a prerequisite for an in-development open-source user space
> >> driver stack that will allow to use ISM devices to provide remote
> >> console and block device functionality. This stack will be part of
> >> s390-tools.
> >> 
> >> This driver would also allow QEMU to mediate access to an ISM device,
> >> enabling a form of PCI pass-through even for guests whose hardware
> >> cannot directly execute PCI accesses, such as nested guests.
> >> 
> >> On s390, kernel primitives such as ioread() and iowrite() are switched
> >> over from function handle based PCI load/stores instructions to PCI
> >> memory-I/O (MIO) loads/stores when these are available and not
> >> explicitly disabled. Since these instructions cannot be used with ISM
> >> devices, ensure that classic function handle-based PCI instructions are
> >> used instead.
> >> 
> >> The driver is still required even when MIO instructions are disabled, as
> >> the ISM device relies on the PCI store‑block (PCISTB) instruction to
> >> perform write operations.
> >> 
> >> Thank you,
> >> Julian
> >> 
> >> Signed-off-by: Julian Ruess <julianr@linux.ibm.com>
> >> ---
> >> Changes in v4:
> >> - Fix bug with < 8 byte reads. For code simplicity, only support 8 byte reads.  
> >
> > Does the ISM device define sub-8-byte accesses as valid?  It looks like
> > if pread() doesn't return the desired size QEMU will fill the return
> > with -1.  Unless such accesses are classified as undefined by ISM,
> > doesn't that suggest a potential data corruption issue to the guest
> > driver?  Thanks,
> >
> > Alex  
> 
> 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

  reply	other threads:[~2026-03-16 19:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13 14:40 [PATCH v4 0/3] vfio/pci: Introduce vfio_pci driver for ISM devices Julian Ruess
2026-03-13 14:40 ` [PATCH v4 1/3] vfio/pci: Rename vfio_config_do_rw() to vfio_pci_config_rw_single() and export it Julian Ruess
2026-03-13 14:40 ` [PATCH v4 2/3] vfio/ism: Implement vfio_pci driver for ISM devices Julian Ruess
2026-03-13 14:40 ` [PATCH v4 3/3] MAINTAINERS: add VFIO ISM PCI DRIVER section Julian Ruess
2026-03-13 15:41 ` [PATCH v4 0/3] vfio/pci: Introduce vfio_pci driver for ISM devices Alex Williamson
2026-03-16 12:33   ` Julian Ruess
2026-03-16 19:03     ` Alex Williamson [this message]
2026-03-17 10:01       ` Niklas Schnelle

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=20260316130305.21e015ef@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.