linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: <ankita@nvidia.com>
To: <ankita@nvidia.com>, <jgg@nvidia.com>, <maz@kernel.org>,
	<oliver.upton@linux.dev>, <joey.gouly@arm.com>,
	<suzuki.poulose@arm.com>, <yuzenghui@huawei.com>,
	<catalin.marinas@arm.com>, <will@kernel.org>,
	<ryan.roberts@arm.com>, <shahuang@redhat.com>,
	<lpieralisi@kernel.org>, <david@redhat.com>
Cc: <aniketa@nvidia.com>, <cjia@nvidia.com>, <kwankhede@nvidia.com>,
	<targupta@nvidia.com>, <vsethi@nvidia.com>, <acurrid@nvidia.com>,
	<apopple@nvidia.com>, <jhubbard@nvidia.com>, <danw@nvidia.com>,
	<zhiw@nvidia.com>, <mochs@nvidia.com>, <udhoke@nvidia.com>,
	<dnigam@nvidia.com>, <alex.williamson@redhat.com>,
	<sebastianene@google.com>, <coltonlewis@google.com>,
	<kevin.tian@intel.com>, <yi.l.liu@intel.com>, <ardb@kernel.org>,
	<akpm@linux-foundation.org>, <gshan@redhat.com>,
	<linux-mm@kvack.org>, <ddutile@redhat.com>, <tabba@google.com>,
	<qperret@google.com>, <seanjc@google.com>,
	<kvmarm@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: [PATCH v3 0/1] KVM: arm64: Map GPU device memory as cacheable
Date: Mon, 10 Mar 2025 10:30:07 +0000	[thread overview]
Message-ID: <20250310103008.3471-1-ankita@nvidia.com> (raw)

From: Ankit Agrawal <ankita@nvidia.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 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.

The changes are heavily influenced by the discussions between
Catalin Marinas, David Hildenbrand and Jason Gunthorpe [1] on v2.
Many thanks for their valuable suggestions.

Applied over next-20250305 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@nvidia.com). NVIDIA has provided git repositories which
includes all the requisite kernel [3] and Qemu [4] patches in case
one wants to try.

v2 -> v3
1. Restricted the new changes to check for cacheability to VM_PFNMAP
   based on David Hildenbrand's (david@redhat.com) suggestion.
2. Removed the MTE checks based on Jason Gunthorpe's (jgg@nvidia.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@arm.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/20241118131958.4609-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 (1):
  KVM: arm64: Allow cacheable stage 2 mapping using VMA flags

 arch/arm64/include/asm/kvm_pgtable.h |  8 ++++++
 arch/arm64/kvm/hyp/pgtable.c         |  2 +-
 arch/arm64/kvm/mmu.c                 | 43 +++++++++++++++++++++++++++-
 3 files changed, 51 insertions(+), 2 deletions(-)

-- 
2.34.1



             reply	other threads:[~2025-03-10 10:30 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 10:30 ankita [this message]
2025-03-10 10:30 ` [PATCH v3 1/1] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags ankita
2025-03-10 11:54   ` Marc Zyngier
2025-03-11  3:42     ` Ankit Agrawal
2025-03-11 11:18       ` Marc Zyngier
2025-03-11 12:07         ` Ankit Agrawal
2025-03-12  8:21           ` Marc Zyngier
2025-03-17  5:55             ` Ankit Agrawal
2025-03-17  9:27               ` Marc Zyngier
2025-03-17 19:54                 ` Catalin Marinas
2025-03-18  9:39                   ` Marc Zyngier
2025-03-18 12:55                     ` Jason Gunthorpe
2025-03-18 19:27                       ` Catalin Marinas
2025-03-18 19:35                         ` David Hildenbrand
2025-03-18 19:40                           ` Oliver Upton
2025-03-20  3:30                             ` bibo mao
2025-03-20  7:24                               ` bibo mao
2025-03-18 23:17                         ` Jason Gunthorpe
2025-03-19 18:03                           ` Catalin Marinas
2025-03-18 19:30                       ` Oliver Upton
2025-03-18 23:09                         ` Jason Gunthorpe
2025-03-19  7:01                           ` Oliver Upton
2025-03-19 17:04                             ` Jason Gunthorpe
2025-03-19 18:11                               ` Catalin Marinas
2025-03-19 19:22                                 ` Jason Gunthorpe
2025-03-19 21:48                                   ` Catalin Marinas
2025-03-26  8:31                                     ` Ankit Agrawal
2025-03-26 14:53                                       ` Sean Christopherson
2025-03-26 15:42                                         ` Marc Zyngier
2025-03-26 16:10                                           ` Sean Christopherson
2025-03-26 18:02                                             ` Marc Zyngier
2025-03-26 18:24                                               ` Sean Christopherson
2025-03-26 18:51                                                 ` Oliver Upton
2025-03-31 14:44                                                   ` Jason Gunthorpe
2025-03-31 14:56                                                 ` Jason Gunthorpe
2025-04-07 15:20                                                   ` Sean Christopherson
2025-04-07 16:15                                                     ` Jason Gunthorpe
2025-04-07 16:43                                                       ` Sean Christopherson
2025-04-16  8:51                                                         ` Ankit Agrawal
2025-04-21 16:03                                                           ` Ankit Agrawal
2025-04-22  7:49                                                           ` Oliver Upton
2025-04-22 13:54                                                             ` Jason Gunthorpe
2025-04-22 16:50                                                               ` Catalin Marinas
2025-04-22 17:03                                                                 ` Jason Gunthorpe
2025-04-22 21:28                                                                   ` Oliver Upton
2025-04-22 23:35                                                                     ` Jason Gunthorpe
2025-04-23 10:45                                                                       ` Catalin Marinas
2025-04-23 12:02                                                                         ` Jason Gunthorpe
2025-04-23 12:26                                                                           ` Catalin Marinas
2025-04-23 13:03                                                                             ` Jason Gunthorpe
2025-04-29 10:47                                                                               ` Ankit Agrawal
2025-04-29 13:27                                                                                 ` Catalin Marinas
2025-04-29 14:14                                                                                   ` Jason Gunthorpe
2025-04-29 16:03                                                                                     ` Catalin Marinas
2025-04-29 16:44                                                                                       ` Jason Gunthorpe
2025-04-29 18:09                                                                                         ` Catalin Marinas
2025-04-29 18:19                                                                                           ` Jason Gunthorpe
2025-05-07 15:26                                                                                             ` Ankit Agrawal
2025-05-09 12:47                                                                                               ` Catalin Marinas
2025-04-22 14:53                                                             ` Sean Christopherson
2025-03-18 12:57     ` Jason Gunthorpe

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=20250310103008.3471-1-ankita@nvidia.com \
    --to=ankita@nvidia.com \
    --cc=acurrid@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=aniketa@nvidia.com \
    --cc=apopple@nvidia.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cjia@nvidia.com \
    --cc=coltonlewis@google.com \
    --cc=danw@nvidia.com \
    --cc=david@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=dnigam@nvidia.com \
    --cc=gshan@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=joey.gouly@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=kwankhede@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lpieralisi@kernel.org \
    --cc=maz@kernel.org \
    --cc=mochs@nvidia.com \
    --cc=oliver.upton@linux.dev \
    --cc=qperret@google.com \
    --cc=ryan.roberts@arm.com \
    --cc=seanjc@google.com \
    --cc=sebastianene@google.com \
    --cc=shahuang@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=targupta@nvidia.com \
    --cc=udhoke@nvidia.com \
    --cc=vsethi@nvidia.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=yuzenghui@huawei.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