[PATCH v3 1/2] s390x/pci: Free FMB timer on zPCI device unplug

[PATCH v3 1/2] s390x/pci: Free FMB timer on zPCI device unplug

[Farhan Ali]

On an SCLP deconfigure we don't clean up the FMB timer. If there is a
pending unplug request then we can destroy the S390PCIBusDevice object
without correctly cleaning up the timer. So fmb_update() will then run on
freed memory. Clean up the FMB timer before we destroy the S390PCIBusDevice
object to prevent this use after free.

When FMB was introduced with commit 6e92c70c37 ("s390x/pci: add common
function measurement block") we originally cleaned up the FMB timer in
s390_pcihost_unplug(). This behavior was changed in the re-work done with
commit e0998fe89104 ("s390x/pci: Introduce unplug requests and split unplug
handler").

Fixes: e0998fe89104 ("s390x/pci: Introduce unplug requests and split unplug handler")
Cc: qemu-stable@nongnu.org
Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
---
 hw/s390x/s390-pci-bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index cdd75cdfd2..32f78a1f21 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -1400,6 +1400,7 @@ static void s390_pcihost_unplug(const HotplugHandler *hotplug_dev, DeviceState *
     } else if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
         pbdev = S390_PCI_DEVICE(dev);
         pbdev->fid = 0;
+        fmb_timer_free(pbdev);
         QTAILQ_REMOVE(&s->zpci_devs, pbdev, link);
         g_hash_table_remove(s->zpci_table, &pbdev->idx);
         if (pbdev->dma_limit) {
-- 
2.43.0

[PATCH v3 2/2] s390x/pci: Change reset method from legacy to resettable exit

[Farhan Ali]

On subsystem reset of the s390 PCI host bridge (TYPE_S390_PCI_HOST_BRIDGE),
child buses S390PCIBus and PCIBus are reset in order. Because S390PCIBus
devices are reset first via the legacy reset hook, IOMMU mappings are torn
down before the PCI device itself is reset. For a PCI passthrough device
this opens a window where the device may issue DMA to addresses that no
longer have valid IOMMU mappings, causing an error (PEC 0x7) on the host.

The QEMU reset documentation (docs/devel/reset.rst) specifies that IOMMUs
should perform teardown in the resettable 'exit' phase, after all devices
have completed their 'hold' phase. Move the S390PCIBusDevice reset logic
from the legacy reset hook to the resettable exit phase to close this
window.

Fixes: 3e5cfba3ca0a ("s390x/pci: introduce S390PCIBusDevice qdev")
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Tested-by: Omar Elghoul <oelghoul@linux.ibm.com>
Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
---
 hw/s390x/s390-pci-bus.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 32f78a1f21..69832e9cf1 100644
--- a/hw/s390x/s390-pci-bus.c
+++ b/hw/s390x/s390-pci-bus.c
@@ -1786,9 +1786,9 @@ static void s390_pci_device_realize(DeviceState *dev, Error **errp)
     zpci->fmb.format = ZPCI_FMB_FORMAT;
 }
 
-static void s390_pci_device_reset(DeviceState *dev)
+static void s390_pci_device_reset_exit(Object *obj, ResetType type)
 {
-    S390PCIBusDevice *pbdev = S390_PCI_DEVICE(dev);
+    S390PCIBusDevice *pbdev = S390_PCI_DEVICE(obj);
 
     switch (pbdev->state) {
     case ZPCI_FS_RESERVED:
@@ -2019,10 +2019,11 @@ static const VMStateDescription s390_pci_device_vmstate = {
 static void s390_pci_device_class_init(ObjectClass *klass, const void *data)
 {
     DeviceClass *dc = DEVICE_CLASS(klass);
+    ResettableClass *rc = RESETTABLE_CLASS(klass);
 
     dc->desc = "zpci device";
     set_bit(DEVICE_CATEGORY_MISC, dc->categories);
-    device_class_set_legacy_reset(dc, s390_pci_device_reset);
+    rc->phases.exit = s390_pci_device_reset_exit;
     dc->bus_type = TYPE_S390_PCI_BUS;
     dc->realize = s390_pci_device_realize;
     device_class_set_props(dc, s390_pci_device_properties);
-- 
2.43.0

Re: [PATCH v3 2/2] s390x/pci: Change reset method from legacy to resettable exit

[Matthew Rosato]

On 10/28/26 6:46 PM, Farhan Ali wrote:
> On subsystem reset of the s390 PCI host bridge (TYPE_S390_PCI_HOST_BRIDGE),
> child buses S390PCIBus and PCIBus are reset in order. Because S390PCIBus
> devices are reset first via the legacy reset hook, IOMMU mappings are torn
> down before the PCI device itself is reset. For a PCI passthrough device
> this opens a window where the device may issue DMA to addresses that no
> longer have valid IOMMU mappings, causing an error (PEC 0x7) on the host.
> 
> The QEMU reset documentation (docs/devel/reset.rst) specifies that IOMMUs
> should perform teardown in the resettable 'exit' phase, after all devices
> have completed their 'hold' phase. Move the S390PCIBusDevice reset logic
> from the legacy reset hook to the resettable exit phase to close this
> window.
> 
> Fixes: 3e5cfba3ca0a ("s390x/pci: introduce S390PCIBusDevice qdev")
> Cc: qemu-stable@nongnu.org
> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
> Tested-by: Omar Elghoul <oelghoul@linux.ibm.com>
> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

Re: [PATCH v3 2/2] s390x/pci: Change reset method from legacy to resettable exit

[Eric Farman]

On 10/29/26 1:56 PM, Matthew Rosato wrote:
> On 10/28/26 6:46 PM, Farhan Ali wrote:
>> On subsystem reset of the s390 PCI host bridge (TYPE_S390_PCI_HOST_BRIDGE),
>> child buses S390PCIBus and PCIBus are reset in order. Because S390PCIBus
>> devices are reset first via the legacy reset hook, IOMMU mappings are torn
>> down before the PCI device itself is reset. For a PCI passthrough device
>> this opens a window where the device may issue DMA to addresses that no
>> longer have valid IOMMU mappings, causing an error (PEC 0x7) on the host.
>>
>> The QEMU reset documentation (docs/devel/reset.rst) specifies that IOMMUs
>> should perform teardown in the resettable 'exit' phase, after all devices
>> have completed their 'hold' phase. Move the S390PCIBusDevice reset logic
>> from the legacy reset hook to the resettable exit phase to close this
>> window.
>>
>> Fixes: 3e5cfba3ca0a ("s390x/pci: introduce S390PCIBusDevice qdev")
>> Cc: qemu-stable@nongnu.org
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
>> Tested-by: Omar Elghoul <oelghoul@linux.ibm.com>
>> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> 
> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>

Thanks! Applied both of these to the queue for 11.2.

Re: [PATCH v3 1/2] s390x/pci: Free FMB timer on zPCI device unplug

[Matthew Rosato]

On 10/28/26 6:46 PM, Farhan Ali wrote:
> On an SCLP deconfigure we don't clean up the FMB timer. If there is a
> pending unplug request then we can destroy the S390PCIBusDevice object
> without correctly cleaning up the timer. So fmb_update() will then run on
> freed memory. Clean up the FMB timer before we destroy the S390PCIBusDevice
> object to prevent this use after free.
> 
> When FMB was introduced with commit 6e92c70c37 ("s390x/pci: add common
> function measurement block") we originally cleaned up the FMB timer in
> s390_pcihost_unplug(). This behavior was changed in the re-work done with
> commit e0998fe89104 ("s390x/pci: Introduce unplug requests and split unplug
> handler").
> 
> Fixes: e0998fe89104 ("s390x/pci: Introduce unplug requests and split unplug handler")
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>