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>
Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com>
---
hw/s390x/s390-pci-bus.c | 62 ++++++++++++++++++++++++++++----
hw/s390x/s390-pci-inst.c | 4 +--
include/hw/s390x/s390-pci-inst.h | 1 +
3 files changed, 59 insertions(+), 8 deletions(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 4de7b587e8..a104e550b1 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -592,14 +592,64 @@ 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) {
+ pbdev->state = ZPCI_FS_ERROR;
+ s390_pci_generate_error_event(error, pbdev->fh, pbdev->fid, curr,
+ 0);
+ 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 {
+ /*
+ * There is no reliable method to request the guest to release
+ * mappings other than in response to a RPCIT instruction;
+ * generate a permanent error condition and require the device
+ * to be completely re-initialized from the guest side.
+ */
+ pbdev->state = ZPCI_FS_ERROR;
+ s390_pci_generate_error_event(ERR_EVENT_PERMERR, pbdev->fh,
+ pbdev->fid, 0, 0);
+ 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
On 6/4/2026 7:17 PM, Konstantin Shkolnyy wrote:
> 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>
> Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com>
> ---
> hw/s390x/s390-pci-bus.c | 62 ++++++++++++++++++++++++++++----
> hw/s390x/s390-pci-inst.c | 4 +--
> include/hw/s390x/s390-pci-inst.h | 1 +
> 3 files changed, 59 insertions(+), 8 deletions(-)
>
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 4de7b587e8..a104e550b1 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -592,14 +592,64 @@ 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;
> + }
I am curious, how would migration work if direct mapping is used? How is
the IOMMU state replicated on the target machine?
> +
> + 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) {
> + pbdev->state = ZPCI_FS_ERROR;
> + s390_pci_generate_error_event(error, pbdev->fh, pbdev->fid, curr,
> + 0);
> + 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 {
> + /*
> + * There is no reliable method to request the guest to release
> + * mappings other than in response to a RPCIT instruction;
> + * generate a permanent error condition and require the device
> + * to be completely re-initialized from the guest side.
> + */
> + pbdev->state = ZPCI_FS_ERROR;
> + s390_pci_generate_error_event(ERR_EVENT_PERMERR, pbdev->fh,
> + pbdev->fid, 0, 0);
> + 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
On 6/9/26 6:07 PM, Farhan Ali wrote:
>
> On 6/4/2026 7:17 PM, Konstantin Shkolnyy wrote:
>> 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>
>> Signed-off-by: Konstantin Shkolnyy <kshk@linux.ibm.com>
>> ---
>> hw/s390x/s390-pci-bus.c | 62 ++++++++++++++++++++++++++++----
>> hw/s390x/s390-pci-inst.c | 4 +--
>> include/hw/s390x/s390-pci-inst.h | 1 +
>> 3 files changed, 59 insertions(+), 8 deletions(-)
>>
>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>> index 4de7b587e8..a104e550b1 100644
>> --- a/hw/s390x/s390-pci-bus.c
>> +++ b/hw/s390x/s390-pci-bus.c
>> @@ -592,14 +592,64 @@ 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;
>> + }
>
> I am curious, how would migration work if direct mapping is used? How is the IOMMU state replicated on the target machine?
Hm, good question.
For this series, it's not really an issue; emulated devices are always
disallowed from direct mapping and only emulated devices are being
enabled for migration here (passthrough devices are still fenced) --
so you'll never take this path during a migration with this series.
When I wrote this patch I was testing the VFIO reset case where we will
get a new MPCFIC from the guest to drive reg_ioat(). But you're right,
that won't happen with a migration; rather migration code will need
specific handling to re-trigger the mapping done in reg_ioat() for
direct-mapped devices in order to fill the host IOMMU without a guest
IOMMU to replay.
Actually, I believe Konstantin is doing the necessary work already in
patch 14 via a call to s390_pci_iommu_direct_map_enable() during
s390_pci_device_post_load().
Thanks,
Matt
© 2016 - 2026 Red Hat, Inc.