From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Farhan Ali <alifm@linux.ibm.com>,
Konstantin Shkolnyy <kshk@linux.ibm.com>
Cc: 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: Re: [PATCH v4 01/15] s390x/pci: implement IOMMU replay
Date: Fri, 24 Jul 2026 15:37:38 -0400 [thread overview]
Message-ID: <ac601753-088a-4412-bc4f-ef6e38dc381e@linux.ibm.com> (raw)
In-Reply-To: <74c3efe9-41e4-4db1-a1b3-f0ceb48809a3@linux.ibm.com>
On 7/24/26 3:10 PM, Farhan Ali wrote:
>
> On 7/23/2026 8:09 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 eff980fdfe..511926c151 100644
>> --- a/hw/s390x/s390-pci-bus.c
>> +++ b/hw/s390x/s390-pci-bus.c
>> @@ -593,14 +593,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;
>
> This patch doesn't compile on its own. Trying to compile with just this
> patch gives the error:
>
> i-bus.c.o -c ../hw/s390x/s390-pci-bus.c
> ../hw/s390x/s390-pci-bus.c: In function ‘s390_pci_ioat_replay’:
> ../hw/s390x/s390-pci-bus.c:620:13: error: ‘pbdev’ undeclared (first use
> in this function)
> 620 | pbdev->state = ZPCI_FS_ERROR;
> | ^~~~~
> ../hw/s390x/s390-pci-bus.c:620:13: note: each undeclared identifier is
> reported only once for each function it appears in
>
> This should be fixed to avoid breaking git bisectability.
>
Oh, thanks for pointing this out. Not sure what happened here, I
thought I wrote the new version and tested it independent of this
series, but maybe I did it on top where we get pbdev as an input to
s390_pci_ioat_replay() and then botched the rebase. That sounds most
likely, but I can't find my working branch at this point.
In any event, doing a S390PCIBusDevice *pbdev = iommu->pbdev; upfront
would be the most straightforward solution, and then it will go away in
patch 3 to instead be replaced by S390PCIIOMMU *iommu = pbdev->iommu;
Konstantin, I can send you another version or you can do that yourself,
up to you.
Here's a diff against this patch of what I mean, with a little extra
defensive programming:
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 511926c151..21bca4d787 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -595,6 +595,7 @@ err:
static void s390_pci_ioat_replay(S390PCIIOMMU *iommu)
{
+ S390PCIBusDevice *pbdev = iommu->pbdev;
S390IOTLBEntry entry;
uint16_t error = 0;
uint32_t dma_avail;
@@ -603,7 +604,7 @@ static void s390_pci_ioat_replay(S390PCIIOMMU *iommu)
curr = iommu->pba;
end = iommu->pal;
- if (iommu->dm_mr) {
+ if (iommu->dm_mr || !pbdev) {
/* If direct mapping is used, there are no guest tables to
replay */
return;
}
next prev parent reply other threads:[~2026-07-24 19:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 3:09 [PATCH v4 00/15] s390x/pci: Implement migration for emulated devices Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 01/15] s390x/pci: implement IOMMU replay Konstantin Shkolnyy
2026-07-24 19:10 ` Farhan Ali
2026-07-24 19:37 ` Matthew Rosato [this message]
2026-07-24 3:09 ` [PATCH v4 02/15] s390x/pci: Create function to contain translation status check Konstantin Shkolnyy
2026-07-24 19:11 ` Farhan Ali
2026-07-24 3:09 ` [PATCH v4 03/15] s390x/pci: Move iommu_mr from S390PCIIOMMU to S390PCIBusDevice Konstantin Shkolnyy
2026-07-24 19:26 ` Farhan Ali
2026-07-24 3:09 ` [PATCH v4 04/15] s390x/pci: Move dm_mr " Konstantin Shkolnyy
2026-07-24 19:42 ` Farhan Ali
2026-07-24 3:09 ` [PATCH v4 05/15] s390x/pci: Move iotlb " Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 06/15] s390x/pci: Remove a ptr to S390PCIBusDevice from S390PCIIOMMU Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 07/15] s390x/pci: Move/rename enabled from S390PCIIOMMU to S390PCIBusDevice Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 08/15] s390x/pci: Move dma_limit " Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 09/15] s390x/pci: Move g_iota " Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 10/15] s390x/pci: Move pba " Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 11/15] s390x/pci: Move pal " Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 12/15] s390x/pci: Move max_dma_limit " Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 13/15] s390x/pci: Add a comment explaining S390PCIIOMMU purpose Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 14/15] s390x/pci: Implement migration for emulated devices Konstantin Shkolnyy
2026-07-24 3:09 ` [PATCH v4 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=ac601753-088a-4412-bc4f-ef6e38dc381e@linux.ibm.com \
--to=mjrosato@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=kshk@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.