public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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 v5 0/7] vfio/nvgrace-gpu: Support huge PFNMAP and wait for GPU ready post reset
Date: Mon, 24 Nov 2025 11:59:19 +0000	[thread overview]
Message-ID: <20251124115926.119027-1-ankita@nvidia.com> (raw)

From: Ankit Agrawal <ankita@nvidia.com>

NVIDIA's Grace based system have large GPU device memory. The device
memory is mapped as VM_PFNMAP in the VMM VMA. The nvgrace-gpu
module could make use of the huge PFNMAP support added in mm [1].

To achieve this, nvgrace-gpu module is updated to implement huge_fault ops.
The implementation establishes mapping according to the order request.
Note that if the PFN or the VMA address is unaligned to the order, the
mapping fallbacks to the PTE level.

Secondly, it is expected that the mapping not be re-established until
the GPU is ready post reset. Presence of the mappings during that time
could potentially leads to harmless corrected RAS events to be logged if
the CPU attempts to do speculative reads on the GPU memory on the Grace
systems.

It can take several seconds for the GPU to be ready. So it is desirable
that the time overlaps as much of the VM startup as possible to reduce
impact on the VM bootup time. The GPU readiness state is thus checked
on the first fault/huge_fault request which amortizes the GPU readiness
time. The GPU readiness is checked through BAR0 registers as is done
at the device probe.

Patch 1 updates the mapping mechanism to be done through faults.

Patch 2 splits the code to map at the various levels.

Patch 3 implements support for huge pfnmap.

Patch 4 vfio_pci_core_mmap cleanup.

Patch 5 split the code to check the device readiness.

Patch 6 reset_done handler implementation

Patch 7 Ensures that the GPU is ready before re-establishing the mapping
after reset.

Applied over 6.18-rc6.

Link: https://lore.kernel.org/all/20240826204353.2228736-1-peterx@redhat.com/ [1]

Changelog:
v5:
- Updated gpu_mem_mapped with reset_done flag for clearer semantics. (6/7)
  (Thanks Alex Williamson)
- Renamed vfio_pci_map_pfn to vfio_pci_vmf_insert_pfn. (2/7)
  (Thanks Alex Williamson)
- Updated to hold memory_lock across the vmf_insert_pfn and the
  read/write access of the device. (7/7) (Thanks Alex Williamson)
- Used scoped_guard to simplify critical region. (1/7, 7/7)
[v4]
- Implemented reset_done handler to set gpu_mem_mapped flag. Cleaned up
  FLR detection path (Thanks Alex Williamson)
- Moved the premap check of the device readiness to a new function.
  Added locking to avoid races. (Thanks Alex Williamson)
- vfio_pci_core_mmap cleanup.
- Added ioremap to BAR0 during open.
Link: https://lore.kernel.org/all/20251121141141.3175-1-ankita@nvidia.com/ [v3]
- Moved the code for BAR mapping to a separate function.
- Added BAR0 mapping during open. Ensures BAR0 is mapped when registers
  are checked. (Thanks Alex Williamson, Jason Gunthorpe for suggestion)
- Added check for GPU readiness on nvgrace_gpu_map_device_mem. (Thanks
  Alex Williamson for the suggestion.
Link: https://lore.kernel.org/all/20251118074422.58081-1-ankita@nvidia.com/ [v2]
- Fixed build kernel warning
- subject text changes
- Rebased to 6.18-rc6.
Link: https://lore.kernel.org/all/20251117124159.3560-1-ankita@nvidia.com/ [v1]

Signed-off-by: Ankit Agrawal <ankita@nvidia.com>

Ankit Agrawal (7):
  vfio/nvgrace-gpu: Use faults to map device memory
  vfio: export function to map the VMA
  vfio/nvgrace-gpu: Add support for huge pfnmap
  vfio: use vfio_pci_core_setup_barmap to map bar in mmap
  vfio/nvgrace-gpu: split the code to wait for GPU ready
  vfio/nvgrace-gpu: Inform devmem unmapped after reset
  vfio/nvgrace-gpu: wait for the GPU mem to be ready

 drivers/vfio/pci/nvgrace-gpu/main.c | 216 ++++++++++++++++++++++------
 drivers/vfio/pci/vfio_pci_core.c    |  61 ++++----
 include/linux/vfio_pci_core.h       |   2 +
 3 files changed, 207 insertions(+), 72 deletions(-)

-- 
2.34.1


             reply	other threads:[~2025-11-24 11:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-24 11:59 ankita [this message]
2025-11-24 11:59 ` [PATCH v5 1/7] vfio/nvgrace-gpu: Use faults to map device memory ankita
2025-11-24 17:09   ` Shameer Kolothum
2025-11-24 17:16     ` Jason Gunthorpe
2025-11-24 17:16   ` Jason Gunthorpe
2025-11-24 11:59 ` [PATCH v5 2/7] vfio: export function to map the VMA ankita
2025-11-24 17:22   ` Shameer Kolothum
2025-11-24 11:59 ` [PATCH v5 3/7] vfio/nvgrace-gpu: Add support for huge pfnmap ankita
2025-11-24 15:32   ` Alex Williamson
2025-11-24 15:40     ` Ankit Agrawal
2025-11-24 18:08   ` Shameer Kolothum
2025-11-24 18:15   ` Jason Gunthorpe
2025-11-24 11:59 ` [PATCH v5 4/7] vfio: use vfio_pci_core_setup_barmap to map bar in mmap ankita
2025-11-24 18:10   ` Shameer Kolothum
2025-11-24 11:59 ` [PATCH v5 5/7] vfio/nvgrace-gpu: split the code to wait for GPU ready ankita
2025-11-24 15:32   ` Alex Williamson
2025-11-24 15:39     ` Ankit Agrawal
2025-11-24 18:22   ` Shameer Kolothum
2025-11-25  2:53     ` Ankit Agrawal
2025-11-24 11:59 ` [PATCH v5 6/7] vfio/nvgrace-gpu: Inform devmem unmapped after reset ankita
2025-11-24 18:16   ` Jason Gunthorpe
2025-11-25  2:52     ` Ankit Agrawal
2025-11-24 11:59 ` [PATCH v5 7/7] vfio/nvgrace-gpu: wait for the GPU mem to be ready ankita
2025-11-24 18:41   ` Shameer Kolothum

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=20251124115926.119027-1-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