From: Donald Dutile <ddutile@redhat.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,
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: Re: [PATCH v5 2/5] KVM: arm64: New function to determine hardware cache management support
Date: Fri, 23 May 2025 15:36:16 -0400 [thread overview]
Message-ID: <9b429da4-8db6-407e-9721-178e01fd1ebb@redhat.com> (raw)
In-Reply-To: <9ffc7686-0dc0-4978-8cd8-f12a1c148b63@redhat.com>
On 5/23/25 3:30 PM, Donald Dutile wrote:
>
>
> On 5/23/25 11:44 AM, ankita@nvidia.com wrote:
>> 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);
> Won't this cause a build warning on non-ARM builds, b/c there is no
> resolution of this function for the other arch's?
> Need #ifdef or default-rtn-0 function for arch's that don't have this function?
>
ah, I see you have the weak function in patch 5/5.
But I think you have to move that hunk to this patch, so a bisect won't cause
a build warning (or failure, depending on how a distro sets -W in its builds).
- Don
>> int kvm_prefetch_pages(struct kvm_memory_slot *slot, gfn_t gfn,
>> struct page **pages, int nr_pages);
next prev parent reply other threads:[~2025-05-23 19:36 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 ` [PATCH v5 2/5] KVM: arm64: New function to determine hardware cache management support ankita
2025-05-23 19:30 ` Donald Dutile
2025-05-23 19:36 ` Donald Dutile [this message]
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=9b429da4-8db6-407e-9721-178e01fd1ebb@redhat.com \
--to=ddutile@redhat.com \
--cc=acurrid@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=aniketa@nvidia.com \
--cc=ankita@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=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.