From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 0/3] KVM: arm64: Load the stage-2 MMU from vcpu_load() for VHE
Date: Fri, 06 Oct 2023 13:34:34 +0100 [thread overview]
Message-ID: <861qe8nd45.wl-maz@kernel.org> (raw)
In-Reply-To: <8634yongw3.wl-maz@kernel.org>
On Fri, 06 Oct 2023 12:13:00 +0100,
Marc Zyngier <maz@kernel.org> wrote:
>
> On Fri, 06 Oct 2023 10:35:57 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > Unlike nVHE, there is no need to switch the stage-2 MMU around on guest
> > entry/exit in VHE mode as the host is running at EL2. Despite this KVM
> > reloads the stage-2 on every guest entry, which is needless.
> >
> > This series moves the setup of the stage-2 MMU context to vcpu_load()
> > when running in VHE mode. This is likely to be a win across the board,
> > but also allows us to remove an ISB on the guest entry path for systems
> > with one of the speculative AT errata.
> >
> > None of my machines affected by the AT errata are VHE-capable, so it'd
> > be appreciated if someone could give this series a go and make sure I
> > haven't wrecked anything.
>
> It totally breaks on my A55 board. Running a single guest seems OK,
> but running a number of the concurrently makes them explode early on
> (faults in EFI...)
>
> I guess we end-up running with the wrong VTTBR at times, which would
> be interesting...
Fun fact:
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index b0cafd7c5f8f..40c84db5884a 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -195,6 +195,11 @@ static int __kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
sysreg_restore_guest_state_vhe(guest_ctxt);
__debug_switch_to_guest(vcpu);
+ WARN_ONCE(kvm_get_vttbr(vcpu->arch.hw_mmu) != read_sysreg(vttbr_el2),
+ "Oh crap %llx vs %llx\n",
+ kvm_get_vttbr(vcpu->arch.hw_mmu),
+ read_sysreg(vttbr_el2));
+
if (is_hyp_ctxt(vcpu))
vcpu_set_flag(vcpu, VCPU_HYP_CONTEXT);
else
[ 36.190355] Oh crap 10000057a6001 vs 57a6001
My bet is that the VMID isn't allocated on first load, and everything
goes downhill from there.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2023-10-06 12:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 9:35 [PATCH 0/3] KVM: arm64: Load the stage-2 MMU from vcpu_load() for VHE Oliver Upton
2023-10-06 9:35 ` [PATCH 1/3] KVM: arm64: Don't zero VTTBR in __tlb_switch_to_host() Oliver Upton
2023-10-06 9:41 ` Oliver Upton
2023-10-06 9:35 ` [PATCH 2/3] KVM: arm64: Rename helpers for VHE vCPU load/put Oliver Upton
2023-10-06 22:06 ` kernel test robot
2023-10-06 9:36 ` [PATCH 3/3] KVM: arm64: Load the stage-2 MMU context in kvm_vcpu_load_vhe() Oliver Upton
2023-10-06 11:13 ` [PATCH 0/3] KVM: arm64: Load the stage-2 MMU from vcpu_load() for VHE Marc Zyngier
2023-10-06 12:34 ` Marc Zyngier [this message]
2023-10-06 13:33 ` Marc Zyngier
2023-10-06 15:03 ` Marc Zyngier
2023-10-06 18:11 ` 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=861qe8nd45.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--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.