From: Matthew Rosato <mjrosato@linux.ibm.com>
To: qemu-s390x@nongnu.org
Cc: farman@linux.ibm.com, kvm@vger.kernel.org, pmorel@linux.ibm.com,
schnelle@linux.ibm.com, cohuck@redhat.com,
richard.henderson@linaro.org, thuth@redhat.com,
qemu-devel@nongnu.org, pasic@linux.ibm.com,
alex.williamson@redhat.com, mst@redhat.com, pbonzini@redhat.com,
david@redhat.com, borntraeger@linux.ibm.com
Subject: [PATCH v5 0/9] s390x/pci: zPCI interpretation support
Date: Mon, 4 Apr 2022 14:17:17 -0400 [thread overview]
Message-ID: <20220404181726.60291-1-mjrosato@linux.ibm.com> (raw)
For QEMU, the majority of the work in enabling instruction interpretation
is handled via SHM bit settings (to indicate to firmware whether or not
interpretive execution facilities are to be used) + a new KVM ioctl is
used to setup firmware-interpreted forwarding of Adapter Event
Notifications.
This series also adds a new, optional 'interpret' parameter to zpci which
can be used to disable interpretation support (interpret=off) as well as
an 'forwarding_assist' parameter to determine whether or not the firmware
assist will be used for adapter event delivery (default when
interpretation is in use) or whether the host will be responsible for
delivering all adapter event notifications (forwarding_assist=off).
The ZPCI_INTERP CPU feature is added beginning with the z14 model to
enable this support.
As a consequence of implementing zPCI interpretation, ISM devices now
become eligible for passthrough (but only when zPCI interpretation is
available).
From the perspective of guest configuration, you passthrough zPCI devices
in the same manner as before, with intepretation support being used by
default if available in kernel+qemu.
Will reply with a link to the associated kernel series.
Changelog v4->v5:
- Update to match latest interface from kernel code. Major changes are:
1) we no longer issue any ioctls to set a device to interpreted mode;
rather, this will be done automatically if supported by the host kernel
at the time the vfio group is associated with the KVM. Then, the SHM
bit setting will indicate whether or not interpretation is actually
used.
2) the RPCIT enhancments (IOMMU changes) are removed from this series,
so the code associated with indicating a desired IOMMU are also
removed. With this series s390x-pci will continue to use only type1
IOMMU for now.
- Refresh the linux headers sync. Added a patch to tolerate some vfio
uapi renames that will happen in 5.18 (this can be discarded if there
is something else underway to address this)
Matthew Rosato (9):
Update linux headers
vfio: tolerate migration protocol v1 uapi renames
target/s390x: add zpci-interp to cpu models
s390x/pci: add routine to get host function handle from CLP info
s390x/pci: enable for load/store intepretation
s390x/pci: don't fence interpreted devices without MSI-X
s390x/pci: enable adapter event notification for interpreted devices
s390x/pci: let intercept devices have separate PCI groups
s390x/pci: reflect proper maxstbl for groups of interpreted devices
hw/s390x/meson.build | 1 +
hw/s390x/s390-pci-bus.c | 107 ++++-
hw/s390x/s390-pci-inst.c | 52 ++-
hw/s390x/s390-pci-kvm.c | 51 +++
hw/s390x/s390-pci-vfio.c | 129 +++++-
hw/s390x/s390-virtio-ccw.c | 1 +
hw/vfio/common.c | 2 +-
hw/vfio/migration.c | 19 +-
include/hw/s390x/s390-pci-bus.h | 8 +-
include/hw/s390x/s390-pci-kvm.h | 38 ++
include/hw/s390x/s390-pci-vfio.h | 6 +
.../linux/input-event-codes.h | 4 +-
.../standard-headers/linux/virtio_config.h | 6 +
.../standard-headers/linux/virtio_crypto.h | 82 +++-
linux-headers/asm-arm64/kvm.h | 16 +
linux-headers/asm-generic/mman-common.h | 2 +
linux-headers/asm-mips/mman.h | 2 +
linux-headers/asm-s390/kvm.h | 1 +
linux-headers/linux/kvm.h | 50 ++-
linux-headers/linux/psci.h | 4 +
linux-headers/linux/userfaultfd.h | 8 +-
linux-headers/linux/vfio.h | 406 +++++++++---------
linux-headers/linux/vfio_zdev.h | 7 +
linux-headers/linux/vhost.h | 7 +
target/s390x/cpu_features_def.h.inc | 1 +
target/s390x/gen-features.c | 2 +
target/s390x/kvm/kvm.c | 8 +
target/s390x/kvm/kvm_s390x.h | 1 +
28 files changed, 763 insertions(+), 258 deletions(-)
create mode 100644 hw/s390x/s390-pci-kvm.c
create mode 100644 include/hw/s390x/s390-pci-kvm.h
--
2.27.0
next reply other threads:[~2022-04-04 18:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 18:17 Matthew Rosato [this message]
2022-04-04 18:17 ` [PATCH v5 1/9] Update linux headers Matthew Rosato
2022-04-04 18:17 ` [PATCH v5 2/9] vfio: tolerate migration protocol v1 uapi renames Matthew Rosato
2022-04-12 15:50 ` Pierre Morel
2022-04-12 16:07 ` Matthew Rosato
2022-04-19 15:44 ` Pierre Morel
2022-04-04 18:17 ` [PATCH v5 3/9] target/s390x: add zpci-interp to cpu models Matthew Rosato
2022-05-18 8:01 ` Thomas Huth
2022-05-18 8:02 ` Thomas Huth
2022-05-18 8:05 ` Thomas Huth
2022-04-04 18:17 ` [PATCH v5 4/9] s390x/pci: add routine to get host function handle from CLP info Matthew Rosato
2022-04-19 19:15 ` Pierre Morel
2022-05-18 8:13 ` Thomas Huth
2022-04-04 18:17 ` [PATCH v5 5/9] s390x/pci: enable for load/store intepretation Matthew Rosato
2022-04-19 19:47 ` Pierre Morel
2022-04-20 15:12 ` Matthew Rosato
2022-04-22 9:27 ` Pierre Morel
2022-04-04 18:17 ` [PATCH v5 6/9] s390x/pci: don't fence interpreted devices without MSI-X Matthew Rosato
2022-04-04 18:17 ` [PATCH v5 7/9] s390x/pci: enable adapter event notification for interpreted devices Matthew Rosato
2022-04-22 9:39 ` Pierre Morel
2022-04-22 12:10 ` Matthew Rosato
2022-05-02 7:48 ` Pierre Morel
2022-05-02 9:19 ` Niklas Schnelle
2022-05-02 11:30 ` Pierre Morel
2022-05-02 19:57 ` Matthew Rosato
2022-05-03 14:53 ` Pierre Morel
2022-05-04 14:20 ` Matthew Rosato
2022-04-04 18:17 ` [PATCH v5 8/9] s390x/pci: let intercept devices have separate PCI groups Matthew Rosato
2022-04-04 18:17 ` [PATCH v5 9/9] s390x/pci: reflect proper maxstbl for groups of interpreted devices Matthew Rosato
2022-04-19 19:49 ` Pierre Morel
2022-04-22 9:43 ` Pierre Morel
2022-05-06 9:03 ` Pierre Morel
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=20220404181726.60291-1-mjrosato@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=schnelle@linux.ibm.com \
--cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).