From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 2/5] KVM: arm64: nvhe: Synchronise with page table walker on TLBI
Date: Thu, 13 Apr 2023 00:09:20 +0000 [thread overview]
Message-ID: <ZDdIMMv7jhmSqMNi@linux.dev> (raw)
In-Reply-To: <20230408160427.10672-3-maz@kernel.org>
Hi Marc,
On Sat, Apr 08, 2023 at 05:04:24PM +0100, Marc Zyngier wrote:
> A TLBI from EL2 impacting EL1 involves messing with the EL1&0
> translation regime, and the page table walker may still be
> performing speculative walks.
>
> Piggyback on the existing DSBs to always have a DSB ISH that
> will synchronise all load/store operations that the PTW may
> still have.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/hyp/nvhe/tlb.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> index d296d617f589..e86dd04d49ff 100644
> --- a/arch/arm64/kvm/hyp/nvhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -17,6 +17,23 @@ struct tlb_inv_context {
> static void __tlb_switch_to_guest(struct kvm_s2_mmu *mmu,
> struct tlb_inv_context *cxt)
> {
> + /*
> + * We have two requirements:
> + *
> + * - ensure that the page table updates are visible to all
> + * CPUs, for which a dsb(ishst) is what we need
> + *
> + * - complete any speculative page table walk started before
> + * we trapped to EL2 so that we can mess with the MM
> + * registers out of context, for which dsb(nsh) is enough
> + *
> + * The composition of these two barriers is a dsb(ish). This
> + * might be slightly over the top for non-shareable TLBIs, but
> + * they are so vanishingly rare that it isn't worth the
> + * complexity.
> + */
> + dsb(ish);
> +
Ricardo is carrying a patch for non-shareable TLBIs on permission
relaxation [*], and he's found that it produces some rather desirable
performance improvements. I appreciate the elegance of your approach,
but given what's coming does it make sense to have the TLBI handlers
continue to explicitly perform the appropriate DSB?
[*] https://lore.kernel.org/kvmarm/20230409063000.3559991-14-ricarkol@google.com/
> if (cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT)) {
> u64 val;
>
> @@ -60,8 +77,6 @@ void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
> {
> struct tlb_inv_context cxt;
>
> - dsb(ishst);
> -
> /* Switch to requested VMID */
> __tlb_switch_to_guest(mmu, &cxt);
>
> @@ -113,8 +128,6 @@ void __kvm_tlb_flush_vmid(struct kvm_s2_mmu *mmu)
> {
> struct tlb_inv_context cxt;
>
> - dsb(ishst);
> -
> /* Switch to requested VMID */
> __tlb_switch_to_guest(mmu, &cxt);
>
> @@ -142,7 +155,8 @@ void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu)
>
> void __kvm_flush_vm_context(void)
> {
> - dsb(ishst);
> + /* Same remark as in __tblb_switch_to_guest() */
typo: __tlb_switch_to_guest()
> + dsb(ish);
> __tlbi(alle1is);
>
> /*
> --
> 2.34.1
>
>
--
Thanks,
Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 2/5] KVM: arm64: nvhe: Synchronise with page table walker on TLBI
Date: Thu, 13 Apr 2023 00:09:20 +0000 [thread overview]
Message-ID: <ZDdIMMv7jhmSqMNi@linux.dev> (raw)
In-Reply-To: <20230408160427.10672-3-maz@kernel.org>
Hi Marc,
On Sat, Apr 08, 2023 at 05:04:24PM +0100, Marc Zyngier wrote:
> A TLBI from EL2 impacting EL1 involves messing with the EL1&0
> translation regime, and the page table walker may still be
> performing speculative walks.
>
> Piggyback on the existing DSBs to always have a DSB ISH that
> will synchronise all load/store operations that the PTW may
> still have.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/hyp/nvhe/tlb.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> index d296d617f589..e86dd04d49ff 100644
> --- a/arch/arm64/kvm/hyp/nvhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -17,6 +17,23 @@ struct tlb_inv_context {
> static void __tlb_switch_to_guest(struct kvm_s2_mmu *mmu,
> struct tlb_inv_context *cxt)
> {
> + /*
> + * We have two requirements:
> + *
> + * - ensure that the page table updates are visible to all
> + * CPUs, for which a dsb(ishst) is what we need
> + *
> + * - complete any speculative page table walk started before
> + * we trapped to EL2 so that we can mess with the MM
> + * registers out of context, for which dsb(nsh) is enough
> + *
> + * The composition of these two barriers is a dsb(ish). This
> + * might be slightly over the top for non-shareable TLBIs, but
> + * they are so vanishingly rare that it isn't worth the
> + * complexity.
> + */
> + dsb(ish);
> +
Ricardo is carrying a patch for non-shareable TLBIs on permission
relaxation [*], and he's found that it produces some rather desirable
performance improvements. I appreciate the elegance of your approach,
but given what's coming does it make sense to have the TLBI handlers
continue to explicitly perform the appropriate DSB?
[*] https://lore.kernel.org/kvmarm/20230409063000.3559991-14-ricarkol@google.com/
> if (cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT)) {
> u64 val;
>
> @@ -60,8 +77,6 @@ void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu,
> {
> struct tlb_inv_context cxt;
>
> - dsb(ishst);
> -
> /* Switch to requested VMID */
> __tlb_switch_to_guest(mmu, &cxt);
>
> @@ -113,8 +128,6 @@ void __kvm_tlb_flush_vmid(struct kvm_s2_mmu *mmu)
> {
> struct tlb_inv_context cxt;
>
> - dsb(ishst);
> -
> /* Switch to requested VMID */
> __tlb_switch_to_guest(mmu, &cxt);
>
> @@ -142,7 +155,8 @@ void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu)
>
> void __kvm_flush_vm_context(void)
> {
> - dsb(ishst);
> + /* Same remark as in __tblb_switch_to_guest() */
typo: __tlb_switch_to_guest()
> + dsb(ish);
> __tlbi(alle1is);
>
> /*
> --
> 2.34.1
>
>
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-13 0:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-08 16:04 [PATCH v2 0/5] KVM: arm64: Synchronise speculative page table walks on translation regime change Marc Zyngier
2023-04-08 16:04 ` Marc Zyngier
2023-04-08 16:04 ` [PATCH v2 1/5] KVM: arm64: nvhe: Synchronise with page table walker on vcpu run Marc Zyngier
2023-04-08 16:04 ` Marc Zyngier
2023-04-13 0:10 ` Oliver Upton
2023-04-13 0:10 ` Oliver Upton
2023-04-08 16:04 ` [PATCH v2 2/5] KVM: arm64: nvhe: Synchronise with page table walker on TLBI Marc Zyngier
2023-04-08 16:04 ` Marc Zyngier
2023-04-13 0:09 ` Oliver Upton [this message]
2023-04-13 0:09 ` Oliver Upton
2023-04-13 7:37 ` Marc Zyngier
2023-04-13 7:37 ` Marc Zyngier
2023-04-08 16:04 ` [PATCH v2 3/5] KVM: arm64: pkvm: Document the side effects of kvm_flush_dcache_to_poc() Marc Zyngier
2023-04-08 16:04 ` Marc Zyngier
2023-04-13 0:10 ` Oliver Upton
2023-04-13 0:10 ` Oliver Upton
2023-04-08 16:04 ` [PATCH v2 4/5] KVM: arm64: vhe: Synchronise with page table walker on MMU update Marc Zyngier
2023-04-08 16:04 ` Marc Zyngier
2023-04-13 0:11 ` Oliver Upton
2023-04-13 0:11 ` Oliver Upton
2023-04-08 16:04 ` [PATCH v2 5/5] KVM: arm64: vhe: Drop extra isb() on guest exit Marc Zyngier
2023-04-08 16:04 ` Marc Zyngier
2023-04-13 0:15 ` Oliver Upton
2023-04-13 0:15 ` Oliver Upton
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=ZDdIMMv7jhmSqMNi@linux.dev \
--to=oliver.upton@linux.dev \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.