| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87pm4dr0hd.wl-maz@kernel.org>
Date: Thu, 27 Jul 2023 13:40:46 +0100
From: Marc Zyngier <maz@...nel.org>
To: Raghavendra Rao Ananta <rananta@...gle.com>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Huacai Chen <chenhuacai@...nel.org>,
Zenghui Yu <yuzenghui@...wei.com>,
Anup Patel <anup@...infault.org>,
Atish Patra <atishp@...shpatra.org>,
Jing Zhang <jingzhangos@...gle.com>,
Reiji Watanabe <reijiw@...gle.com>,
Colton Lewis <coltonlewis@...gle.com>,
David Matlack <dmatlack@...gle.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
linux-mips@...r.kernel.org, kvm-riscv@...ts.infradead.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Gavin Shan <gshan@...hat.com>
Subject: Re: [PATCH v7 07/12] KVM: arm64: Implement __kvm_tlb_flush_vmid_range()
On Sat, 22 Jul 2023 03:22:46 +0100,
Raghavendra Rao Ananta <rananta@...gle.com> wrote:
>
> Define __kvm_tlb_flush_vmid_range() (for VHE and nVHE)
> to flush a range of stage-2 page-tables using IPA in one go.
> If the system supports FEAT_TLBIRANGE, the following patches
> would conviniently replace global TLBI such as vmalls12e1is
> in the map, unmap, and dirty-logging paths with ripas2e1is
> instead.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@...gle.com>
> Reviewed-by: Gavin Shan <gshan@...hat.com>
> ---
> arch/arm64/include/asm/kvm_asm.h | 3 +++
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 11 +++++++++++
> arch/arm64/kvm/hyp/nvhe/tlb.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/vhe/tlb.c | 27 +++++++++++++++++++++++++++
> 4 files changed, 71 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 7d170aaa2db4..2c27cb8cf442 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -70,6 +70,7 @@ enum __kvm_host_smccc_func {
> __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
> __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,
> __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
> + __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
> __KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context,
> __KVM_HOST_SMCCC_FUNC___kvm_timer_set_cntvoff,
> __KVM_HOST_SMCCC_FUNC___vgic_v3_read_vmcr,
> @@ -229,6 +230,8 @@ extern void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t ipa,
> extern void __kvm_tlb_flush_vmid_ipa_nsh(struct kvm_s2_mmu *mmu,
> phys_addr_t ipa,
> int level);
> +extern void __kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
> + phys_addr_t start, unsigned long pages);
> extern void __kvm_tlb_flush_vmid(struct kvm_s2_mmu *mmu);
>
> extern void __kvm_timer_set_cntvoff(u64 cntvoff);
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index a169c619db60..857d9bc04fd4 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -135,6 +135,16 @@ static void handle___kvm_tlb_flush_vmid_ipa_nsh(struct kvm_cpu_context *host_ctx
> __kvm_tlb_flush_vmid_ipa_nsh(kern_hyp_va(mmu), ipa, level);
> }
>
> +static void
> +handle___kvm_tlb_flush_vmid_range(struct kvm_cpu_context *host_ctxt)
> +{
> + DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
> + DECLARE_REG(phys_addr_t, start, host_ctxt, 2);
> + DECLARE_REG(unsigned long, pages, host_ctxt, 3);
> +
> + __kvm_tlb_flush_vmid_range(kern_hyp_va(mmu), start, pages);
> +}
> +
> static void handle___kvm_tlb_flush_vmid(struct kvm_cpu_context *host_ctxt)
> {
> DECLARE_REG(struct kvm_s2_mmu *, mmu, host_ctxt, 1);
> @@ -327,6 +337,7 @@ static const hcall_t host_hcall[] = {
> HANDLE_FUNC(__kvm_tlb_flush_vmid_ipa),
> HANDLE_FUNC(__kvm_tlb_flush_vmid_ipa_nsh),
> HANDLE_FUNC(__kvm_tlb_flush_vmid),
> + HANDLE_FUNC(__kvm_tlb_flush_vmid_range),
> HANDLE_FUNC(__kvm_flush_cpu_context),
> HANDLE_FUNC(__kvm_timer_set_cntvoff),
> HANDLE_FUNC(__vgic_v3_read_vmcr),
> diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> index b9991bbd8e3f..09347111c2cd 100644
> --- a/arch/arm64/kvm/hyp/nvhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -182,6 +182,36 @@ void __kvm_tlb_flush_vmid_ipa_nsh(struct kvm_s2_mmu *mmu,
> __tlb_switch_to_host(&cxt);
> }
>
> +void __kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
> + phys_addr_t start, unsigned long pages)
> +{
> + struct tlb_inv_context cxt;
> + unsigned long stride;
> +
> + /*
> + * Since the range of addresses may not be mapped at
> + * the same level, assume the worst case as PAGE_SIZE
> + */
> + stride = PAGE_SIZE;
> + start = round_down(start, stride);
> +
> + /* Switch to requested VMID */
> + __tlb_switch_to_guest(mmu, &cxt, false);
> +
> + __flush_tlb_range_op(ipas2e1is, start, pages, stride, 0, 0, false);
I really think we need an abstraction here. All this ASID and user
nonsense shouldn't appear here. Something such as
__flush_s2_tlb_range_op(), which would pass the correct parameters
that this code shouldn't have to worry about.
I'm also a bit concerned by the fact we completely lose the level
here. This is a massive fast-path for the CPU, and we don't make use
of it. It'd be worth thinking of how we can make use of it if at all
possible...
> +
> + dsb(ish);
> + __tlbi(vmalle1is);
> + dsb(ish);
> + isb();
> +
> + /* See the comment in __kvm_tlb_flush_vmid_ipa() */
> + if (icache_is_vpipt())
> + icache_inval_all_pou();
> +
> + __tlb_switch_to_host(&cxt);
Another thing is that it is high time that some of this call gets
refactored. All these helpers are basically the same sequence, only
differing by a couple of lines. Not something we need to do
immediately, but eventually we'll have to bite the bullet.
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists