From: <ankita@nvidia.com>
To: <ankita@nvidia.com>, <jgg@ziepe.ca>, <yishaih@nvidia.com>,
<skolothumtho@nvidia.com>, <kevin.tian@intel.com>,
<alex@shazbot.org>, <aniketa@nvidia.com>, <vsethi@nvidia.com>,
<mochs@nvidia.com>
Cc: <Yunxiang.Li@amd.com>, <yi.l.liu@intel.com>,
<zhangdongdong@eswincomputing.com>, <avihaih@nvidia.com>,
<bhelgaas@google.com>, <peterx@redhat.com>, <pstanner@redhat.com>,
<apopple@nvidia.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <cjia@nvidia.com>,
<kwankhede@nvidia.com>, <targupta@nvidia.com>, <zhiw@nvidia.com>,
<danw@nvidia.com>, <dnigam@nvidia.com>, <kjaju@nvidia.com>
Subject: [PATCH v1 6/6] vfio/nvgrace-gpu: vfio/nvgrace-gpu: wait for the GPU mem to be ready
Date: Mon, 17 Nov 2025 12:41:59 +0000 [thread overview]
Message-ID: <20251117124159.3560-7-ankita@nvidia.com> (raw)
In-Reply-To: <20251117124159.3560-1-ankita@nvidia.com>
From: Ankit Agrawal <ankita@nvidia.com>
Speculative prefetches from CPU to GPU memory until the GPU
is not ready after reset can cause harmless corrected RAS events
to be logged. It is thus expected that the mapping not be
re-established until the GPU is ready post reset.
Wait for the GPU to be ready on the first fault before establishing
CPU mapping to the GPU memory. The GPU readiness can be checked
through BAR0 registers as is already being done at the device probe.
The state is checked on the first fault/huge_fault request using
a flag. Unset the flag on every reset request.
So intercept the following calls to the GPU reset, unset
gpu_mem_mapped. Then use it to determine whether to wait before
mapping.
1. VFIO_DEVICE_RESET ioctl call
2. FLR through config space.
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
---
drivers/vfio/pci/nvgrace-gpu/main.c | 52 +++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c
index fc89c381151a..febca4c2d92d 100644
--- a/drivers/vfio/pci/nvgrace-gpu/main.c
+++ b/drivers/vfio/pci/nvgrace-gpu/main.c
@@ -58,6 +58,8 @@ struct nvgrace_gpu_pci_core_device {
/* Lock to control device memory kernel mapping */
struct mutex remap_lock;
bool has_mig_hw_bug;
+ /* Any GPU memory mapped to the VMA */
+ bool gpu_mem_mapped;
};
static void nvgrace_gpu_init_fake_bar_emu_regs(struct vfio_device *core_vdev)
@@ -102,6 +104,8 @@ static int nvgrace_gpu_open_device(struct vfio_device *core_vdev)
mutex_init(&nvdev->remap_lock);
}
+ nvdev->gpu_mem_mapped = false;
+
vfio_pci_core_finish_enable(vdev);
return 0;
@@ -158,6 +162,24 @@ static vm_fault_t nvgrace_gpu_vfio_pci_huge_fault(struct vm_fault *vmf,
struct mem_region *memregion;
unsigned long pgoff, pfn, addr;
+ /*
+ * If the GPU memory is accessed by the CPU while the GPU is
+ * not ready after reset, it can cause harmless corrected RAS
+ * events to be logged. Make sure the GPU is ready before
+ * establishing the mappings.
+ */
+ if (!nvdev->gpu_mem_mapped) {
+ struct vfio_pci_core_device *vdev = &nvdev->core_device;
+
+ if (!vdev->barmap[0])
+ return VM_FAULT_SIGBUS;
+
+ if (nvgrace_gpu_wait_device_ready(vdev->barmap[0]))
+ return VM_FAULT_SIGBUS;
+
+ nvdev->gpu_mem_mapped = true;
+ }
+
memregion = nvgrace_gpu_memregion(index, nvdev);
if (!memregion)
return ret;
@@ -353,7 +375,17 @@ static long nvgrace_gpu_ioctl(struct vfio_device *core_vdev,
case VFIO_DEVICE_IOEVENTFD:
return -ENOTTY;
case VFIO_DEVICE_RESET:
+ struct nvgrace_gpu_pci_core_device *nvdev =
+ container_of(core_vdev, struct nvgrace_gpu_pci_core_device,
+ core_device.vdev);
nvgrace_gpu_init_fake_bar_emu_regs(core_vdev);
+
+ /*
+ * GPU memory is exposed as device BAR2 (region 4,5).
+ * This would be zapped during GPU reset. Unset
+ * nvdev->gpu_mem_mapped to reflect just that.
+ */
+ nvdev->gpu_mem_mapped = false;
fallthrough;
default:
return vfio_pci_core_ioctl(core_vdev, cmd, arg);
@@ -438,11 +470,14 @@ nvgrace_gpu_write_config_emu(struct vfio_device *core_vdev,
struct nvgrace_gpu_pci_core_device *nvdev =
container_of(core_vdev, struct nvgrace_gpu_pci_core_device,
core_device.vdev);
+ struct vfio_pci_core_device *vdev =
+ container_of(core_vdev, struct vfio_pci_core_device, vdev);
u64 pos = *ppos & VFIO_PCI_OFFSET_MASK;
struct mem_region *memregion = NULL;
size_t register_offset;
loff_t copy_offset;
size_t copy_count;
+ int cap_start = vfio_find_cap_start(vdev, pos);
if (vfio_pci_core_range_intersect_range(pos, count, PCI_BASE_ADDRESS_2,
sizeof(u64), ©_offset,
@@ -461,6 +496,23 @@ nvgrace_gpu_write_config_emu(struct vfio_device *core_vdev,
return copy_count;
}
+ if (vfio_pci_core_range_intersect_range(pos, count, cap_start + PCI_EXP_DEVCTL,
+ sizeof(u16), ©_offset,
+ ©_count, ®ister_offset)) {
+ __le16 val16;
+
+ if (copy_from_user((void *)&val16, buf, copy_count))
+ return -EFAULT;
+
+ /*
+ * GPU memory is exposed as device BAR2 (region 4,5).
+ * This would be zapped during GPU reset. Unset
+ * nvdev->gpu_mem_mapped to reflect just that.
+ */
+ if (val16 & cpu_to_le16(PCI_EXP_DEVCTL_BCR_FLR))
+ nvdev->gpu_mem_mapped = false;
+ }
+
return vfio_pci_core_write(core_vdev, buf, count, ppos);
}
--
2.34.1
next prev parent reply other threads:[~2025-11-17 12:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 12:41 [PATCH v1 0/6] vfio/nvgrace-gpu: Support huge PFNMAP and wait ankita
2025-11-17 12:41 ` [PATCH v1 1/6] vfio/nvgrace-gpu: Use faults to map device memory ankita
2025-11-17 12:41 ` [PATCH v1 2/6] vfio: export function to map the VMA ankita
2025-11-17 12:41 ` [PATCH v1 3/6] vfio/nvgrace-gpu: Add support for huge pfnmap ankita
2025-11-18 6:12 ` kernel test robot
2025-11-17 12:41 ` [PATCH v1 4/6] vfio: export vfio_find_cap_start ankita
2025-11-17 12:41 ` [PATCH v1 5/6] vfio/nvgrace-gpu: split the code to wait for GPU ready ankita
2025-11-17 12:41 ` ankita [this message]
2025-11-18 0:45 ` [PATCH v1 6/6] vfio/nvgrace-gpu: vfio/nvgrace-gpu: wait for the GPU mem to be ready 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=20251117124159.3560-7-ankita@nvidia.com \
--to=ankita@nvidia.com \
--cc=Yunxiang.Li@amd.com \
--cc=alex@shazbot.org \
--cc=aniketa@nvidia.com \
--cc=apopple@nvidia.com \
--cc=avihaih@nvidia.com \
--cc=bhelgaas@google.com \
--cc=cjia@nvidia.com \
--cc=danw@nvidia.com \
--cc=dnigam@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=kjaju@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochs@nvidia.com \
--cc=peterx@redhat.com \
--cc=pstanner@redhat.com \
--cc=skolothumtho@nvidia.com \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=yi.l.liu@intel.com \
--cc=yishaih@nvidia.com \
--cc=zhangdongdong@eswincomputing.com \
--cc=zhiw@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
all inboxes | Powered by JetHome®