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>, <ddutile@redhat.com>,
<seanjc@google.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>, <tabba@google.com>, <qperret@google.com>,
<kvmarm@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <maobibo@loongson.cn>
Subject: [PATCH v7 1/5] KVM: arm64: Rename symbols to reflect whether CMO may be used
Date: Wed, 18 Jun 2025 06:55:37 +0000 [thread overview]
Message-ID: <20250618065541.50049-2-ankita@nvidia.com> (raw)
In-Reply-To: <20250618065541.50049-1-ankita@nvidia.com>
From: Ankit Agrawal <ankita@nvidia.com>
Currently, the kvm_is_device_pfn() detects if the memory is kernel
mapped. It thus implies whether KVM can use Cache Maintenance
Operations (CMOs) on that PFN. Rename the function to reflect this.
Additionally, the "device" variable is effectively trying to setup the S2
to prevent CMOs. Calling it 'disable_cmo' would make this code clearer.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
---
arch/arm64/kvm/mmu.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 2942ec92c5a4..3d77a278fc4f 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -193,9 +193,9 @@ int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm,
return 0;
}
-static bool kvm_is_device_pfn(unsigned long pfn)
+static bool kvm_can_use_cmo_pfn(unsigned long pfn)
{
- return !pfn_is_map_memory(pfn);
+ return pfn_is_map_memory(pfn);
}
static void *stage2_memcache_zalloc_page(void *arg)
@@ -1478,7 +1478,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
int ret = 0;
bool write_fault, writable, force_pte = false;
bool exec_fault, mte_allowed;
- bool device = false, vfio_allow_any_uc = false;
+ bool disable_cmo = false, vfio_allow_any_uc = false;
unsigned long mmu_seq;
phys_addr_t ipa = fault_ipa;
struct kvm *kvm = vcpu->kvm;
@@ -1642,7 +1642,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (is_error_noslot_pfn(pfn))
return -EFAULT;
- if (kvm_is_device_pfn(pfn)) {
+ if (!kvm_can_use_cmo_pfn(pfn)) {
/*
* If the page was identified as device early by looking at
* the VMA flags, vma_pagesize is already representing the
@@ -1653,7 +1653,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
* In both cases, we don't let transparent_hugepage_adjust()
* change things at the last minute.
*/
- device = true;
+ disable_cmo = true;
} else if (logging_active && !write_fault) {
/*
* Only actually map the page as writable if this was a write
@@ -1662,7 +1662,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
writable = false;
}
- if (exec_fault && device)
+ if (exec_fault && disable_cmo)
return -ENOEXEC;
/*
@@ -1695,7 +1695,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
* If we are not forced to use page mapping, check if we are
* backed by a THP and thus use block mapping if possible.
*/
- if (vma_pagesize == PAGE_SIZE && !(force_pte || device)) {
+ if (vma_pagesize == PAGE_SIZE && !(force_pte || disable_cmo)) {
if (fault_is_perm && fault_granule > PAGE_SIZE)
vma_pagesize = fault_granule;
else
@@ -1709,7 +1709,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
}
}
- if (!fault_is_perm && !device && kvm_has_mte(kvm)) {
+ if (!fault_is_perm && !disable_cmo && kvm_has_mte(kvm)) {
/* Check the VMM hasn't introduced a new disallowed VMA */
if (mte_allowed) {
sanitise_mte_tags(kvm, pfn, vma_pagesize);
@@ -1725,7 +1725,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (exec_fault)
prot |= KVM_PGTABLE_PROT_X;
- if (device) {
+ if (disable_cmo) {
if (vfio_allow_any_uc)
prot |= KVM_PGTABLE_PROT_NORMAL_NC;
else
--
2.34.1
next prev parent reply other threads:[~2025-06-18 6:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 6:55 [PATCH v7 0/5] KVM: arm64: Map GPU device memory as cacheable ankita
2025-06-18 6:55 ` ankita [this message]
2025-06-18 14:28 ` [PATCH v7 1/5] KVM: arm64: Rename symbols to reflect whether CMO may be used Catalin Marinas
2025-06-18 14:35 ` Catalin Marinas
2025-06-19 2:22 ` Ankit Agrawal
2025-06-18 6:55 ` [PATCH v7 2/5] KVM: arm64: Block cacheable PFNMAP mapping ankita
2025-06-18 15:46 ` Catalin Marinas
2025-06-19 2:21 ` Ankit Agrawal
2025-06-18 6:55 ` [PATCH v7 3/5] KVM: arm64: New function to determine hardware cache management support ankita
2025-06-18 16:12 ` Catalin Marinas
2025-06-18 6:55 ` [PATCH v7 4/5] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags ankita
2025-06-18 16:34 ` Catalin Marinas
2025-06-18 16:38 ` Jason Gunthorpe
2025-06-19 12:14 ` Ankit Agrawal
2025-06-19 14:16 ` Jason Gunthorpe
2025-06-19 16:03 ` Donald Dutile
2025-06-19 16:46 ` Ankit Agrawal
2025-06-18 6:55 ` [PATCH v7 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=20250618065541.50049-2-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox