From: Alex Williamson <alex.williamson@redhat.com>
To: Farhan Ali <alifm@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, schnelle@linux.ibm.com,
mjrosato@linux.ibm.com
Subject: Re: [PATCH v1 5/6] vfio-pci/zdev: Perform platform specific function reset for zPCI
Date: Wed, 13 Aug 2025 16:56:31 -0600 [thread overview]
Message-ID: <20250813165631.7c22ef0f.alex.williamson@redhat.com> (raw)
In-Reply-To: <7059025f-f337-493d-a50c-ccce8fb4beee@linux.ibm.com>
On Wed, 13 Aug 2025 14:52:24 -0700
Farhan Ali <alifm@linux.ibm.com> wrote:
> On 8/13/2025 1:30 PM, Alex Williamson wrote:
> > On Wed, 13 Aug 2025 10:08:19 -0700
> > Farhan Ali <alifm@linux.ibm.com> wrote:
> >
> >> For zPCI devices we should drive a platform specific function reset
> >> as part of VFIO_DEVICE_RESET. This reset is needed recover a zPCI device
> >> in error state.
> >>
> >> Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
> >> ---
> >> arch/s390/pci/pci.c | 1 +
> >> drivers/vfio/pci/vfio_pci_core.c | 4 ++++
> >> drivers/vfio/pci/vfio_pci_priv.h | 5 ++++
> >> drivers/vfio/pci/vfio_pci_zdev.c | 39 ++++++++++++++++++++++++++++++++
> >> 4 files changed, 49 insertions(+)
> >>
> >> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> >> index f795e05b5001..860a64993b58 100644
> >> --- a/arch/s390/pci/pci.c
> >> +++ b/arch/s390/pci/pci.c
> >> @@ -788,6 +788,7 @@ int zpci_hot_reset_device(struct zpci_dev *zdev)
> >>
> >> return rc;
> >> }
> >> +EXPORT_SYMBOL_GPL(zpci_hot_reset_device);
> >>
> >> /**
> >> * zpci_create_device() - Create a new zpci_dev and add it to the zbus
> >> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> >> index 7dcf5439dedc..7220a22135a9 100644
> >> --- a/drivers/vfio/pci/vfio_pci_core.c
> >> +++ b/drivers/vfio/pci/vfio_pci_core.c
> >> @@ -1227,6 +1227,10 @@ static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev,
> >> */
> >> vfio_pci_set_power_state(vdev, PCI_D0);
> >>
> >> + ret = vfio_pci_zdev_reset(vdev);
> >> + if (ret && ret != -ENODEV)
> >> + return ret;
> >> +
> >> ret = pci_try_reset_function(vdev->pdev);
> >> up_write(&vdev->memory_lock);
> > You're going to be very unhappy if this lock isn't released.
> >
> Ah yes, thanks for catching that. Will fix this.
>
> >
> >>
> >> diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
> >> index a9972eacb293..5288577b3170 100644
> >> --- a/drivers/vfio/pci/vfio_pci_priv.h
> >> +++ b/drivers/vfio/pci/vfio_pci_priv.h
> >> @@ -86,6 +86,7 @@ int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
> >> struct vfio_info_cap *caps);
> >> int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev);
> >> void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev);
> >> +int vfio_pci_zdev_reset(struct vfio_pci_core_device *vdev);
> >> #else
> >> static inline int vfio_pci_info_zdev_add_caps(struct vfio_pci_core_device *vdev,
> >> struct vfio_info_cap *caps)
> >> @@ -100,6 +101,10 @@ static inline int vfio_pci_zdev_open_device(struct vfio_pci_core_device *vdev)
> >>
> >> static inline void vfio_pci_zdev_close_device(struct vfio_pci_core_device *vdev)
> >> {}
> >> +int vfio_pci_zdev_reset(struct vfio_pci_core_device *vdev)
> >> +{
> >> + return -ENODEV;
> >> +}
> >> #endif
> >>
> >> static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
> >> diff --git a/drivers/vfio/pci/vfio_pci_zdev.c b/drivers/vfio/pci/vfio_pci_zdev.c
> >> index 818235b28caa..dd1919ccb3be 100644
> >> --- a/drivers/vfio/pci/vfio_pci_zdev.c
> >> +++ b/drivers/vfio/pci/vfio_pci_zdev.c
> >> @@ -212,6 +212,45 @@ static int vfio_pci_zdev_setup_err_region(struct vfio_pci_core_device *vdev)
> >> return ret;
> >> }
> >>
> >> +int vfio_pci_zdev_reset(struct vfio_pci_core_device *vdev)
> >> +{
> >> + struct zpci_dev *zdev = to_zpci(vdev->pdev);
> >> + int rc = -EIO;
> >> +
> >> + if (!zdev)
> >> + return -ENODEV;
> >> +
> >> + /*
> >> + * If we can't get the zdev->state_lock the device state is
> >> + * currently undergoing a transition and we bail out - just
> >> + * the same as if the device's state is not configured at all.
> >> + */
> >> + if (!mutex_trylock(&zdev->state_lock))
> >> + return rc;
> >> +
> >> + /* We can reset only if the function is configured */
> >> + if (zdev->state != ZPCI_FN_STATE_CONFIGURED)
> >> + goto out;
> >> +
> >> + rc = zpci_hot_reset_device(zdev);
> >> + if (rc != 0)
> >> + goto out;
> >> +
> >> + if (!vdev->pci_saved_state) {
> >> + pci_err(vdev->pdev, "No saved available for the device");
> >> + rc = -EIO;
> >> + goto out;
> >> + }
> >> +
> >> + pci_dev_lock(vdev->pdev);
> >> + pci_load_saved_state(vdev->pdev, vdev->pci_saved_state);
> >> + pci_restore_state(vdev->pdev);
> >> + pci_dev_unlock(vdev->pdev);
> >> +out:
> >> + mutex_unlock(&zdev->state_lock);
> >> + return rc;
> >> +}
> > This looks like it should be a device or arch specific reset
> > implemented in drivers/pci, not vfio. Thanks,
> >
> > Alex
>
> Are you suggesting to move this to an arch specific function? One thing
> we need to do after the zpci_hot_reset_device, is to correctly restore
> the config space of the device. And for vfio-pci bound devices we want
> to restore the state of the device to when it was initially opened.
We generally rely on the abstraction of pci_reset_function() to select
the correct type of reset for a function scope reset. We've gone to
quite a bit of effort to implement all device specific resets and
quirks in the PCI core to be re-used across the kernel.
Calling zpci_hot_reset_device() directly seems contradictory to those
efforts. Should pci_reset_function() call this universally on s390x
rather than providing access to FLR/PM/SBR reset? Why is it
universally correct here given the ioctl previously made use of
standard reset mechanisms?
The DEVICE_RESET ioctl is simply an in-place reset of the device,
without restoring the original device state. So we're also subtly
changing that behavior here, presumably because we're targeting the
specific error recovery case. Have you considered how this might
break non-error-recovery use cases?
I wonder if we want a different reset mechanism for this use case
rather than these subtle semantic changes. Thanks,
Alex
next prev parent reply other threads:[~2025-08-13 22:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 17:08 [PATCH v1 0/6] Error recovery for vfio-pci devices on s390x Farhan Ali
2025-08-13 17:08 ` [PATCH v1 1/6] s390/pci: Restore airq unconditionally for the zPCI device Farhan Ali
2025-08-14 11:32 ` Niklas Schnelle
2025-08-14 16:42 ` Farhan Ali
2025-08-13 17:08 ` [PATCH v1 2/6] s390/pci: Update the logic for detecting passthrough device Farhan Ali
2025-08-13 17:08 ` [PATCH v1 3/6] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2025-08-13 17:08 ` [PATCH v1 4/6] vfio-pci/zdev: Setup a zpci memory region for error information Farhan Ali
2025-08-13 20:30 ` Alex Williamson
2025-08-13 21:25 ` Farhan Ali
2025-08-13 21:42 ` Alex Williamson
2025-08-13 17:08 ` [PATCH v1 5/6] vfio-pci/zdev: Perform platform specific function reset for zPCI Farhan Ali
2025-08-13 20:30 ` Alex Williamson
2025-08-13 21:52 ` Farhan Ali
2025-08-13 22:56 ` Alex Williamson [this message]
2025-08-14 13:12 ` Niklas Schnelle
2025-08-14 16:33 ` Farhan Ali
2025-08-14 19:55 ` Niklas Schnelle
2025-08-14 20:57 ` Alex Williamson
2025-08-14 22:33 ` Farhan Ali
2025-08-14 5:22 ` kernel test robot
2025-08-14 7:42 ` kernel test robot
2025-08-13 17:08 ` [PATCH v1 6/6] vfio: Allow error notification and recovery for ISM device Farhan Ali
2025-08-14 20:48 ` Bjorn Helgaas
2025-08-14 21:02 ` Farhan Ali
2025-08-15 20:48 ` Alex Williamson
2025-08-15 21:36 ` Farhan Ali
2025-08-13 17:45 ` [PATCH v1 0/6] Error recovery for vfio-pci devices on s390x Farhan Ali
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=20250813165631.7c22ef0f.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=alifm@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).