From: Quentin Perret <qperret@google.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
Jade Alglave <jade.alglave@arm.com>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
kvmarm@lists.cs.columbia.edu, linux-arch@vger.kernel.org
Subject: Re: [PATCH 4/4] KVM: arm64: Upgrade VMID accesses to {READ,WRITE}_ONCE
Date: Fri, 6 Aug 2021 15:24:56 +0100 [thread overview]
Message-ID: <YQ1GOAqlG9+25XS4@google.com> (raw)
In-Reply-To: <20210806113109.2475-6-will@kernel.org>
On Friday 06 Aug 2021 at 12:31:08 (+0100), Will Deacon wrote:
> From: Marc Zyngier <maz@kernel.org>
>
> Since TLB invalidation can run in parallel with VMID allocation,
> we need to be careful and avoid any sort of load/store tearing.
> Use {READ,WRITE}_ONCE consistently to avoid any surprise.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jade Alglave <jade.alglave@arm.com>
> Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/include/asm/kvm_mmu.h | 7 ++++++-
> arch/arm64/kvm/arm.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 4 ++--
> arch/arm64/kvm/mmu.c | 2 +-
> 4 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 934ef0deff9f..5828dd8fa738 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -252,6 +252,11 @@ static inline int kvm_write_guest_lock(struct kvm *kvm, gpa_t gpa,
>
> #define kvm_phys_to_vttbr(addr) phys_to_ttbr(addr)
>
> +/*
> + * When this is (directly or indirectly) used on the TLB invalidation
> + * path, we rely on a previously issued DSB so that page table updates
> + * and VMID reads are correctly ordered.
> + */
> static __always_inline u64 kvm_get_vttbr(struct kvm_s2_mmu *mmu)
> {
> struct kvm_vmid *vmid = &mmu->vmid;
> @@ -259,7 +264,7 @@ static __always_inline u64 kvm_get_vttbr(struct kvm_s2_mmu *mmu)
> u64 cnp = system_supports_cnp() ? VTTBR_CNP_BIT : 0;
>
> baddr = mmu->pgd_phys;
> - vmid_field = (u64)vmid->vmid << VTTBR_VMID_SHIFT;
> + vmid_field = (u64)READ_ONCE(vmid->vmid) << VTTBR_VMID_SHIFT;
> return kvm_phys_to_vttbr(baddr) | vmid_field | cnp;
> }
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index e9a2b8f27792..658f76067f46 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -571,7 +571,7 @@ static void update_vmid(struct kvm_vmid *vmid)
> kvm_call_hyp(__kvm_flush_vm_context);
> }
>
> - vmid->vmid = kvm_next_vmid;
> + WRITE_ONCE(vmid->vmid, kvm_next_vmid);
> kvm_next_vmid++;
> kvm_next_vmid &= (1 << kvm_get_vmid_bits()) - 1;
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index d4e74ca7f876..55ae97a144b8 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -109,8 +109,8 @@ int kvm_host_prepare_stage2(void *pgt_pool_base)
> mmu->pgd_phys = __hyp_pa(host_kvm.pgt.pgd);
> mmu->arch = &host_kvm.arch;
> mmu->pgt = &host_kvm.pgt;
> - mmu->vmid.vmid_gen = 0;
> - mmu->vmid.vmid = 0;
> + WRITE_ONCE(mmu->vmid.vmid_gen, 0);
> + WRITE_ONCE(mmu->vmid.vmid, 0);
I'm guessing it should be safe to omit those? But they certainly don't
harm and can serve as documentation anyway, so:
Reviewed-by: Quentin Perret <qperret@google.com>
Thanks,
Quentin
>
> return 0;
> }
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 3155c9e778f0..b1a6eaec28ff 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -485,7 +485,7 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu)
> mmu->arch = &kvm->arch;
> mmu->pgt = pgt;
> mmu->pgd_phys = __pa(pgt->pgd);
> - mmu->vmid.vmid_gen = 0;
> + WRITE_ONCE(mmu->vmid.vmid_gen, 0);
> return 0;
>
> out_destroy_pgtable:
> --
> 2.32.0.605.g8dce9f2422-goog
>
next prev parent reply other threads:[~2021-08-06 14:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-06 11:31 [PATCH 0/4] Fix racing TLBI with ASID/VMID reallocation Will Deacon
2021-08-06 11:31 ` [PATCH 1/4] arm64: mm: Fix TLBI vs ASID rollover Will Deacon
2021-08-06 11:59 ` Catalin Marinas
2021-08-06 12:42 ` Will Deacon
2021-08-06 12:49 ` Catalin Marinas
2021-08-06 11:31 ` [PATCH] of: restricted dma: Don't fail device probe on rmem init failure Will Deacon
2021-08-06 11:34 ` Will Deacon
2021-08-06 11:31 ` [PATCH 2/4] KVM: arm64: Move kern_hyp_va() usage in __load_guest_stage2() into the callers Will Deacon
2021-08-06 11:31 ` [PATCH 3/4] KVM: arm64: Convert the host S2 over to __load_guest_stage2() Will Deacon
2021-08-06 13:40 ` Quentin Perret
2021-08-20 8:01 ` Marc Zyngier
2021-08-20 9:08 ` Quentin Perret
2021-08-06 11:31 ` [PATCH 4/4] KVM: arm64: Upgrade VMID accesses to {READ,WRITE}_ONCE Will Deacon
2021-08-06 14:24 ` Quentin Perret [this message]
2021-08-06 16:04 ` (subset) [PATCH 0/4] Fix racing TLBI with ASID/VMID reallocation Catalin Marinas
2021-09-10 9:06 ` Shameerali Kolothum Thodi
2021-09-10 9:45 ` Catalin Marinas
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=YQ1GOAqlG9+25XS4@google.com \
--to=qperret@google.com \
--cc=catalin.marinas@arm.com \
--cc=jade.alglave@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=will@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).