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>,
<kjaju@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>, <maobibo@loongson.cn>
Subject: [PATCH v5 2/5] KVM: arm64: New function to determine hardware cache management support
Date: Fri, 23 May 2025 15:44:42 +0000 [thread overview]
Message-ID: <20250523154445.3779-3-ankita@nvidia.com> (raw)
In-Reply-To: <20250523154445.3779-1-ankita@nvidia.com>
From: Ankit Agrawal <ankita@nvidia.com>
The hardware supports safely mapping PFNMAP as cacheable if it
is capable of managing cache. This can be determined by the presence
of FWB (Force Write Back) and CACHE_DIC feature.
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. 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 contingent on these two hardware features.
Introduce a new function to make the check for presence of those
features.
CC: David Hildenbrand <david@redhat.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
---
arch/arm64/kvm/mmu.c | 12 ++++++++++++
include/linux/kvm_host.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 305a0e054f81..124655da02ca 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1287,6 +1287,18 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
kvm_nested_s2_wp(kvm);
}
+/**
+ * kvm_arch_supports_cacheable_pfnmap() - Determine whether hardware
+ * supports cache management.
+ *
+ * Return: True if FWB and DIC is supported.
+ */
+bool kvm_arch_supports_cacheable_pfnmap(void)
+{
+ return cpus_have_final_cap(ARM64_HAS_STAGE2_FWB) &&
+ cpus_have_final_cap(ARM64_HAS_CACHE_DIC);
+}
+
static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
{
send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 291d49b9bf05..3750d216d456 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1231,6 +1231,8 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm);
/* flush memory translations pointing to 'slot' */
void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
struct kvm_memory_slot *slot);
+/* hardware support cache management */
+bool kvm_arch_supports_cacheable_pfnmap(void);
int kvm_prefetch_pages(struct kvm_memory_slot *slot, gfn_t gfn,
struct page **pages, int nr_pages);
--
2.34.1
next prev parent reply other threads:[~2025-05-23 15:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 15:44 [PATCH v5 0/5] KVM: arm64: Map GPU device memory as cacheable ankita
2025-05-23 15:44 ` [PATCH v5 1/5] KVM: arm64: Block cacheable PFNMAP mapping ankita
2025-05-23 15:44 ` ankita [this message]
2025-05-23 19:30 ` [PATCH v5 2/5] KVM: arm64: New function to determine hardware cache management support Donald Dutile
2025-05-23 19:36 ` Donald Dutile
2025-05-24 1:41 ` Ankit Agrawal
2025-05-24 2:38 ` Donald Dutile
2025-05-23 15:44 ` [PATCH v5 3/5] kvm: arm64: New memslot flag to indicate cacheable mapping ankita
2025-05-23 15:44 ` [PATCH v5 4/5] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags ankita
2025-05-23 15:44 ` [PATCH v5 5/5] KVM: arm64: Expose new KVM cap for cacheable PFNMAP ankita
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=20250523154445.3779-3-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=kjaju@nvidia.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=maobibo@loongson.cn \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.