Message-ID: <20250518054754.5345-1-ankita@nvidia.com>
Date: Sun, 18 May 2025 05:47:49 +0000
From: <ankita@...dia.com>
To: <ankita@...dia.com>, <jgg@...dia.com>, <maz@...nel.org>,
	<oliver.upton@...ux.dev>, <joey.gouly@....com>, <suzuki.poulose@....com>,
	<yuzenghui@...wei.com>, <catalin.marinas@....com>, <will@...nel.org>,
	<ryan.roberts@....com>, <shahuang@...hat.com>, <lpieralisi@...nel.org>,
	<david@...hat.com>
CC: <aniketa@...dia.com>, <cjia@...dia.com>, <kwankhede@...dia.com>,
	<kjaju@...dia.com>, <targupta@...dia.com>, <vsethi@...dia.com>,
	<acurrid@...dia.com>, <apopple@...dia.com>, <jhubbard@...dia.com>,
	<danw@...dia.com>, <zhiw@...dia.com>, <mochs@...dia.com>,
	<udhoke@...dia.com>, <dnigam@...dia.com>, <alex.williamson@...hat.com>,
	<sebastianene@...gle.com>, <coltonlewis@...gle.com>, <kevin.tian@...el.com>,
	<yi.l.liu@...el.com>, <ardb@...nel.org>, <akpm@...ux-foundation.org>,
	<gshan@...hat.com>, <linux-mm@...ck.org>, <ddutile@...hat.com>,
	<tabba@...gle.com>, <qperret@...gle.com>, <seanjc@...gle.com>,
	<kvmarm@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <maobibo@...ngson.cn>
Subject: [PATCH v4 0/5] KVM: arm64: Map GPU device memory as cacheable

From: Ankit Agrawal <ankita@...dia.com>

Grace based platforms such as Grace Hopper/Blackwell Superchips have
CPU accessible cache coherent GPU memory. The GPU device memory is
essentially a DDR memory and retains properties such as cacheability,
unaligned accesses, atomics and handling of executable faults. This
requires the device memory to be mapped as NORMAL in stage-2.

Today KVM forces the memory to either NORMAL or DEVICE_nGnRE depending
on whethere the memory region is added to the kernel. The KVM code is
thus restrictive and prevents device memory that is not added to the
kernel to be marked as cacheable. The patch aims to solve this.

A cachebility check is made if the VM_PFNMAP is set in VMA flags by
consulting the VMA pgprot value. If the pgprot mapping type is MT_NORMAL,
it is considered safe to be mapped cacheable as the KVM S2 will have
the same Normal memory type as the VMA has in the S1 and KVM has no
additional responsibility for safety.

Note when FWB (Force Write Back) is not enabled, the kernel expects to
trivially do cache management by flushing the memory by linearly
converting a kvm_pte to phys_addr to a KVA. The cache management thus
relies on memory being mapped. Since the GPU device memory is not kernel
mapped, exit when the FWB is not supported. Similarly, ARM64_HAS_CACHE_DIC
allows KVM to avoid flushing the icache and turns icache_inval_pou() into
a NOP. So the cacheable PFNMAP is made contingent on these two hardware
features.

The ability to safely do the cacheable mapping of PFNMAP is exposed
through a KVM capability. The userspace is supposed to query it and
consequently set a new memslot flag if it desire to do such mapping.

The changes are heavily influenced by the discussions among
maintainers Marc Zyngier and Oliver Upton besides Jason Gunthorpe,
Catalin Marinas and Sean Christopherson [1] on v3. Many thanks for
their valuable suggestions.

Applied over next-20250407 and tested on the Grace Hopper and
Grace Blackwell platforms by booting up VM, loading NVIDIA module [2]
and running nvidia-smi in the VM.

To run CUDA workloads, there is a dependency on the IOMMUFD and the
Nested Page Table patches being worked on separately by Nicolin Chen.
(nicolinc@...dia.com). NVIDIA has provided git repositories which
includes all the requisite kernel [3] and Qemu [4] patches in case
one wants to try.

v3 -> v4
1. Fixed a security bug due to mismatched attributes between S1 and
S2 mapping to move it to a separate patch. Suggestion by
Jason Gunthorpe (jgg@...dia.com).
2. New minor patch to change the scope of the FWB support indicator
function.
3. Patch to introduce a new memslot flag. Suggestion by Oliver Upton
(oliver.upton@...ux.dev) and Marc Zyngier (maz@...nel.org)
4. Patch to introduce a new KVM cap to expose cacheable PFNMAP support.
Suggestion by Marc Zyngier (maz@...nel.org).
5. Added checks for ARM64_HAS_CACHE_DIC. Suggestion by Catalin Marinas
(catalin.marinas@....com)

v2 -> v3
1. Restricted the new changes to check for cacheability to VM_PFNMAP
   based on David Hildenbrand's (david@...hat.com) suggestion.
2. Removed the MTE checks based on Jason Gunthorpe's (jgg@...dia.com)
   observation that it already done earlier in
   kvm_arch_prepare_memory_region.
3. Dropped the pfn_valid() checks based on suggestions by
   Catalin Marinas (catalin.marinas@....com).
4. Removed the code for exec fault handling as it is not needed
   anymore.

v1 -> v2
1. Removed kvm_is_device_pfn() as a determiner for device type memory
   determination. Instead using pfn_valid()
2. Added handling for MTE.
3. Minor cleanup.

Link: https://lore.kernel.org/all/20250310103008.3471-1-ankita@nvidia.com [1]
Link: https://github.com/NVIDIA/open-gpu-kernel-modules [2]
Link: https://github.com/NVIDIA/NV-Kernels/tree/6.8_ghvirt [3]
Link: https://github.com/NVIDIA/QEMU/tree/6.8_ghvirt_iommufd_vcmdq [4]

Ankit Agrawal (5):
  KVM: arm64: Block cacheable PFNMAP mapping
  KVM: arm64: Make stage2_has_fwb global scope
  kvm: arm64: New memslot flag to indicate cacheable mapping
  KVM: arm64: Allow cacheable stage 2 mapping using VMA flags
  KVM: arm64: Expose new KVM cap for cacheable PFNMAP

 Documentation/virt/kvm/api.rst       | 17 ++++++++-
 arch/arm64/include/asm/kvm_pgtable.h |  8 +++++
 arch/arm64/kvm/arm.c                 |  8 +++++
 arch/arm64/kvm/hyp/pgtable.c         |  2 +-
 arch/arm64/kvm/mmu.c                 | 54 ++++++++++++++++++++++++++--
 include/uapi/linux/kvm.h             |  2 ++
 virt/kvm/kvm_main.c                  |  6 ++--
 7 files changed, 91 insertions(+), 6 deletions(-)

-- 
2.34.1

Powered by blists - more mailing lists