From: Shameer Kolothum <skolothumtho@nvidia.com>
To: <kvm@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: <alex@shazbot.org>, <jgg@ziepe.ca>, <kevin.tian@intel.com>,
<kbusch@meta.com>, <michal.winiarski@intel.com>,
<satyanarayana.k.v.p@intel.com>, <sonangp@nvidia.com>,
<nathanc@nvidia.com>, <mochs@nvidia.com>
Subject: [RFC PATCH 11/19] vfio/pci: Serialize runtime PM with recovery
Date: Tue, 1 Sep 2026 10:32:09 +0100 [thread overview]
Message-ID: <20260901093217.8539-12-skolothumtho@nvidia.com> (raw)
In-Reply-To: <20260901093217.8539-1-skolothumtho@nvidia.com>
Hold recovery_lock for reading around low-power entry and exit. Entry
zaps the BAR mappings and revokes the DMA-BUF exports under memory_lock,
and exit restores the exports. Taking recovery_lock first keeps the same
order the AER callbacks use.
Neither wakes the device. Entry only decrements the runtime PM usage
count, and the suspend which follows runs when the vfio core drops its
own reference after the ioctl returns, outside the lock. Exit takes a
reference without resuming. So neither reaches pci_bus_sem while
recovery_lock is held.
Check the recovery state before the runtime resume in the region read and
write path, but do not hold recovery_lock across it. A resume takes
pci_bus_sem, through pcie_aspm_pm_state_change() and, from D3cold,
through pci_bridge_wait_for_secondary_bus(), and the error callbacks take
recovery_lock from under it.
The check is best effort. It avoids waking a device whose access is
already blocked, and the region access which follows takes recovery_lock
for itself. A recovery which starts after the check is not excluded, and
does not need to be. pcie_do_recovery() runtime resumes every device
under the bridge and holds the reference until it finishes, so a resume
which runs alongside it does no more than take a reference of its own.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
drivers/vfio/pci/vfio_pci_core.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index bd3d79d28f27..95884e713a4b 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -372,15 +372,21 @@ int vfio_pci_set_power_state(struct vfio_pci_core_device *vdev, pci_power_t stat
static int vfio_pci_runtime_pm_entry(struct vfio_pci_core_device *vdev,
struct eventfd_ctx *efdctx)
{
+ int ret;
+
/*
* The vdev power related flags are protected with 'memory_lock'
* semaphore.
*/
+ ret = vfio_pci_core_access_begin(vdev);
+ if (ret)
+ return ret;
vfio_pci_zap_and_down_write_memory_lock(vdev);
vfio_pci_dma_buf_move(vdev, true);
if (vdev->pm_runtime_engaged) {
up_write(&vdev->memory_lock);
+ vfio_pci_core_access_end(vdev);
return -EINVAL;
}
@@ -388,6 +394,7 @@ static int vfio_pci_runtime_pm_entry(struct vfio_pci_core_device *vdev,
vdev->pm_wake_eventfd_ctx = efdctx;
pm_runtime_put_noidle(&vdev->pdev->dev);
up_write(&vdev->memory_lock);
+ vfio_pci_core_access_end(vdev);
return 0;
}
@@ -483,7 +490,11 @@ static int vfio_pci_core_pm_exit(struct vfio_pci_core_device *vdev, u32 flags,
* already signaled the eventfd and exited low power mode itself.
* pm_runtime_engaged protects the redundant call here.
*/
+ ret = vfio_pci_core_access_begin(vdev);
+ if (ret)
+ return ret;
vfio_pci_runtime_pm_exit(vdev);
+ vfio_pci_core_access_end(vdev);
return 0;
}
@@ -1867,6 +1878,24 @@ static ssize_t vfio_pci_rw(struct vfio_pci_core_device *vdev, char __user *buf,
if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
return -EINVAL;
+ ret = vfio_pci_core_access_begin(vdev);
+ if (ret)
+ return ret;
+ vfio_pci_core_access_end(vdev);
+
+ /*
+ * Resume with the guard dropped. A resume takes pci_bus_sem, through
+ * pcie_aspm_pm_state_change() and, from D3cold, through
+ * pci_bridge_wait_for_secondary_bus(). The error callbacks take
+ * recovery_lock from under pci_bus_sem, so holding it here would
+ * invert the order.
+ *
+ * The check above only avoids waking a device whose access is already
+ * blocked. A recovery which starts in between is not excluded, and
+ * does not need to be. pcie_do_recovery() has already resumed every
+ * device under the bridge and holds the reference until it finishes.
+ * The region access below takes the guard for itself.
+ */
ret = pm_runtime_resume_and_get(&vdev->pdev->dev);
if (ret) {
pci_info_ratelimited(vdev->pdev, "runtime resume failed %d\n",
--
2.43.0
next prev parent reply other threads:[~2026-09-01 9:34 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 9:31 [RFC PATCH 00/19] vfio/pci: Handle PCI error recovery and report state to userspace Shameer Kolothum
2026-09-01 9:31 ` [RFC PATCH 01/19] vfio/pci: Add PCI error recovery support state Shameer Kolothum
2026-09-01 9:45 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 02/19] vfio/pci: Serialize generic device lifetime with recovery Shameer Kolothum
2026-09-01 9:47 ` sashiko-bot
2026-09-01 13:14 ` K V P, Satyanarayana
2026-09-01 13:37 ` Shameer Kolothum Thodi
2026-09-01 9:32 ` [RFC PATCH 03/19] vfio/pci: Add PCI recovery access guards Shameer Kolothum
2026-09-01 9:39 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 04/19] vfio/pci: Serialize function reset with recovery Shameer Kolothum
2026-09-01 9:45 ` sashiko-bot
2026-09-02 6:06 ` K V P, Satyanarayana
2026-09-03 11:20 ` Shameer Kolothum Thodi
2026-09-01 9:32 ` [RFC PATCH 05/19] vfio/pci: Serialize config access " Shameer Kolothum
2026-09-01 9:46 ` sashiko-bot
2026-09-02 6:27 ` K V P, Satyanarayana
2026-09-03 11:08 ` Shameer Kolothum Thodi
2026-09-01 9:32 ` [RFC PATCH 06/19] vfio/pci: Serialize ioeventfd writes " Shameer Kolothum
2026-09-01 9:43 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 07/19] vfio/pci: Retry BAR faults after temporary recovery Shameer Kolothum
2026-09-01 9:47 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 08/19] vfio/pci: Serialize BAR and ROM access with recovery Shameer Kolothum
2026-09-01 9:48 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 09/19] vfio/pci: Serialize interrupt operations " Shameer Kolothum
2026-09-01 9:42 ` sashiko-bot
2026-09-03 6:34 ` K V P, Satyanarayana
2026-09-03 10:39 ` Shameer Kolothum Thodi
2026-09-01 9:32 ` [RFC PATCH 10/19] vfio/pci: Serialize hot reset " Shameer Kolothum
2026-09-01 9:58 ` sashiko-bot
2026-09-01 9:32 ` Shameer Kolothum [this message]
2026-09-01 9:49 ` [RFC PATCH 11/19] vfio/pci: Serialize runtime PM " sashiko-bot
2026-09-03 6:43 ` K V P, Satyanarayana
2026-09-03 10:47 ` Shameer Kolothum Thodi
2026-09-01 9:32 ` [RFC PATCH 12/19] vfio/pci: Serialize physical device information queries " Shameer Kolothum
2026-09-01 9:48 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 13/19] vfio/pci: Serialize DMA-BUF export " Shameer Kolothum
2026-09-01 9:43 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 14/19] vfio/pci: Add generic PCI error slot reset handling Shameer Kolothum
2026-09-01 9:53 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 15/19] vfio/pci: Add INTx helpers for PCI recovery Shameer Kolothum
2026-09-01 9:59 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 16/19] vfio/pci: Quiesce INTx during " Shameer Kolothum
2026-09-01 9:53 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 17/19] vfio/pci: Add generic PCI error resume handling Shameer Kolothum
2026-09-01 9:55 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 18/19] vfio/pci: Coordinate generic device access with host recovery Shameer Kolothum
2026-09-01 9:56 ` sashiko-bot
2026-09-01 9:32 ` [RFC PATCH 19/19] vfio/pci: Expose and enable host PCI error recovery Shameer Kolothum
2026-09-01 9:56 ` sashiko-bot
2026-09-04 19:09 ` [RFC PATCH 00/19] vfio/pci: Handle PCI error recovery and report state to userspace Alex Williamson
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=20260901093217.8539-12-skolothumtho@nvidia.com \
--to=skolothumtho@nvidia.com \
--cc=alex@shazbot.org \
--cc=jgg@ziepe.ca \
--cc=kbusch@meta.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=michal.winiarski@intel.com \
--cc=mochs@nvidia.com \
--cc=nathanc@nvidia.com \
--cc=satyanarayana.k.v.p@intel.com \
--cc=sonangp@nvidia.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