qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 3/3] s390x/pci: drive ISM reset from subsystem reset


From: Halil Pasic
Subject: Re: [PATCH v2 3/3] s390x/pci: drive ISM reset from subsystem reset
Date: Fri, 19 Jan 2024 22:07:39 +0100

On Thu, 18 Jan 2024 13:51:51 -0500
Matthew Rosato <mjrosato@linux.ibm.com> wrote:

> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index eaf61d3640..c99682b07d 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -118,6 +118,14 @@ static void subsystem_reset(void)
>      DeviceState *dev;
>      int i;
>  
> +    /*
> +     * ISM firmware is sensitive to unexpected changes to the IOMMU, which 
> can
> +     * occur during reset of the vfio-pci device (unmap of entire aperture).
> +     * Ensure any passthrough ISM devices are reset now, while CPUs are 
> paused
> +     * but before vfio-pci cleanup occurs.
> +     */
> +    s390_pci_ism_reset();

Hm I'm not sure about special casing ISM in here. In my opinion the loop
below shall take care of all the reset.

For TYPE_AP_BRIDGE and TYPE_VIRTUAL_CSS_BRIDGE AFAIU a
device_cold_reset() on all objects of those types results in the resets
of objects that hang below these buses.

I guess this also happens for the S390PCIBusDevices, but not for the
actual PCI devices.

My understanding is that the entire PCI subsystem is to be reset when
a subsystem reset is performed.

I'm not familiar enough with our PCI emulation to know if a reset
to the TYPE_S390_PCI_HOST_BRIDGE is supposed to be sufficient to
accomplish that.

I have the feeling, I am missing something... Can you help me understand
this please?


> +
>      for (i = 0; i < ARRAY_SIZE(reset_dev_types); i++) {
>          dev = DEVICE(object_resolve_path_type("", reset_dev_types[i], NULL));
>          if (dev) 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]