From: Konstantin Shkolnyy <kshk@linux.ibm.com>
To: mjrosato@linux.ibm.com
Cc: alifm@linux.ibm.com, richard.henderson@linaro.org,
iii@linux.ibm.com, david@kernel.org, cohuck@redhat.com,
pasic@linux.ibm.com, borntraeger@linux.ibm.com,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Subject: [PATCH 01/15] s390x/pci: implement IOMMU replay
Date: Wed, 1 Apr 2026 21:29:07 -0500 [thread overview]
Message-ID: <20260402022921.298818-2-kshk@linux.ibm.com> (raw)
In-Reply-To: <20260402022921.298818-1-kshk@linux.ibm.com>
From: Matthew Rosato <mjrosato@linux.ibm.com>
There are a few scenarios where IOMMU replay can potentially be needed
for zPCI device, namely VFIO device reset scenarios where the guest
continues running and expects the contents of its IOMMU to be replayed
upon IOAT re-registration and migration scenarios where the destination
must reconstruct the IOMMU on the destination.
zPCI migration is not supported yet, but the IOMMU replay function is
implemented so that it can be called both from IOMMUMemoryRegionClass
now and migration post_load later.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
---
hw/s390x/s390-pci-bus.c | 50 ++++++++++++++++++++++++++++----
hw/s390x/s390-pci-inst.c | 4 +--
include/hw/s390x/s390-pci-inst.h | 1 +
3 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 4de7b587e8..3665aba106 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -592,14 +592,52 @@ err:
return ret;
}
-static void s390_pci_iommu_replay(IOMMUMemoryRegion *iommu,
+static void s390_pci_ioat_replay(S390PCIIOMMU *iommu)
+{
+ S390IOTLBEntry entry;
+ uint16_t error = 0;
+ uint32_t dma_avail;
+ hwaddr curr, end;
+
+ curr = iommu->pba;
+ end = iommu->pal;
+
+ if (iommu->dm_mr) {
+ /* If direct mapping is used, there are no guest tables to replay */
+ return;
+ }
+
+ if (iommu->dma_limit) {
+ dma_avail = iommu->dma_limit->avail;
+ } else {
+ dma_avail = 1;
+ }
+
+ while (curr < end) {
+ error = s390_guest_io_table_walk(iommu->g_iota, curr, &entry);
+ if (error) {
+ error_report("Failure to walk table during iommu remap");
+ return;
+ }
+
+ if (entry.perm != IOMMU_NONE) {
+ if (dma_avail > 0) {
+ dma_avail = s390_pci_update_iotlb(iommu, &entry);
+ } else {
+ error_report("DMA mappings exhausted: iommu remap failed");
+ return;
+ }
+ }
+ curr += entry.len;
+ }
+}
+
+static void s390_pci_iommu_replay(IOMMUMemoryRegion *mr,
IOMMUNotifier *notifier)
{
- /* It's impossible to plug a pci device on s390x that already has iommu
- * mappings which need to be replayed, that is due to the "one iommu per
- * zpci device" construct. But when we support migration of vfio-pci
- * devices in future, we need to revisit this.
- */
+ S390PCIIOMMU *iommu = container_of(mr, S390PCIIOMMU, iommu_mr);
+
+ s390_pci_ioat_replay(iommu);
}
static S390PCIIOMMU *s390_pci_get_iommu(S390pciState *s, PCIBus *bus,
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 10066ca618..1834596076 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -613,8 +613,8 @@ int pcistg_service_call(S390CPU *cpu, uint8_t r1, uint8_t r2, uintptr_t ra)
return 0;
}
-static uint32_t s390_pci_update_iotlb(S390PCIIOMMU *iommu,
- S390IOTLBEntry *entry)
+uint32_t s390_pci_update_iotlb(S390PCIIOMMU *iommu,
+ S390IOTLBEntry *entry)
{
S390IOTLBEntry *cache = g_hash_table_lookup(iommu->iotlb, &entry->iova);
IOMMUTLBEvent event = {
diff --git a/include/hw/s390x/s390-pci-inst.h b/include/hw/s390x/s390-pci-inst.h
index 5cb8da540b..c782990e3b 100644
--- a/include/hw/s390x/s390-pci-inst.h
+++ b/include/hw/s390x/s390-pci-inst.h
@@ -111,6 +111,7 @@ int mpcifc_service_call(S390CPU *cpu, uint8_t r1, uint64_t fiba, uint8_t ar,
int stpcifc_service_call(S390CPU *cpu, uint8_t r1, uint64_t fiba, uint8_t ar,
uintptr_t ra);
void fmb_timer_free(S390PCIBusDevice *pbdev);
+uint32_t s390_pci_update_iotlb(S390PCIIOMMU *iommu, S390IOTLBEntry *entry);
#define ZPCI_IO_BAR_MIN 0
#define ZPCI_IO_BAR_MAX 5
--
2.34.1
next prev parent reply other threads:[~2026-04-02 2:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 2:29 [PATCH 00/15] s390x/pci: Implement migration for emulated devices Konstantin Shkolnyy
2026-04-02 2:29 ` Konstantin Shkolnyy [this message]
2026-04-08 12:43 ` [PATCH 01/15] s390x/pci: implement IOMMU replay Cornelia Huck
2026-04-02 2:29 ` [PATCH 02/15] s390x/pci: Create function to contain translation status check Konstantin Shkolnyy
2026-04-02 12:03 ` Christian Borntraeger
2026-04-02 2:29 ` [PATCH 03/15] s390x/pci: Move iommu_mr from S390PCIIOMMU to S390PCIBusDevice Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 04/15] s390x/pci: Move dm_mr " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 05/15] s390x/pci: Move iotlb " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 06/15] s390x/pci: Remove a ptr to S390PCIBusDevice from S390PCIIOMMU Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 07/15] s390x/pci: Move/rename enabled from S390PCIIOMMU to S390PCIBusDevice Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 08/15] s390x/pci: Move dma_limit " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 09/15] s390x/pci: Move g_iota " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 10/15] s390x/pci: Move pba " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 11/15] s390x/pci: Move pal " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 12/15] s390x/pci: Move max_dma_limit " Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 13/15] s390x/pci: Add a comment explaining S390PCIIOMMU purpose Konstantin Shkolnyy
2026-04-02 2:29 ` [PATCH 14/15] s390x/pci: Implement migration for emulated devices Konstantin Shkolnyy
2026-04-08 10:01 ` Thomas Huth
2026-04-08 12:28 ` Matthew Rosato
2026-04-08 12:41 ` Cornelia Huck
2026-04-02 2:29 ` [PATCH 15/15] s390x/pci: Create function to contain fmb_timer start Konstantin Shkolnyy
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=20260402022921.298818-2-kshk@linux.ibm.com \
--to=kshk@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@kernel.org \
--cc=iii@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
/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.