From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Brown <broonie@kernel.org>, Gavin Shan <gshan@redhat.com>,
Oliver Upton <oliver.upton@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH 6.12 8/8] KVM: arm64: Eagerly switch ZCR_EL{1,2}
Date: Wed, 19 Mar 2025 10:20:11 +0000 [thread overview]
Message-ID: <Z9qaW_H9UFqdc1bI@J2N7QTR9R3> (raw)
In-Reply-To: <86r02tmldh.wl-maz@kernel.org>
On Wed, Mar 19, 2025 at 09:15:54AM +0000, Marc Zyngier wrote:
> On Wed, 19 Mar 2025 00:26:14 +0000,
> Gavin Shan <gshan@redhat.com> wrote:
> > On 3/14/25 10:35 AM, Mark Brown wrote:
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > index 4e757a77322c9efc59cdff501745f7c80d452358..1c8e2ad32e8c396fc4b11d5fec2e86728f2829d9 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > > @@ -5,6 +5,7 @@
> > > */
> > > #include <hyp/adjust_pc.h>
> > > +#include <hyp/switch.h>
> > > #include <asm/pgtable-types.h>
> > > #include <asm/kvm_asm.h>
> > > @@ -176,8 +177,12 @@ static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
> > > sync_hyp_vcpu(hyp_vcpu);
> > > pkvm_put_hyp_vcpu(hyp_vcpu);
> > > } else {
> > > + struct kvm_vcpu *vcpu = kern_hyp_va(host_vcpu);
> > > +
> > > /* The host is fully trusted, run its vCPU directly. */
> > > - ret = __kvm_vcpu_run(host_vcpu);
> > > + fpsimd_lazy_switch_to_guest(vcpu);
> > > + ret = __kvm_vcpu_run(vcpu);
> > > + fpsimd_lazy_switch_to_host(vcpu);
> > > }
> > >
> >
> > @host_vcpu should have been hypervisor's linear mapping address in v6.12. It looks
> > incorrect to assume it's a kernel's linear mapping address and convert it (@host_vcpu)
> > to the hypervisor's linear address agin, if I don't miss anything.
>
> host_vcpu is passed as a parameter to the hypercall, and is definitely
> a kernel address.
>
> However, at this stage, we have *already* converted it to a HYP VA:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/kvm/hyp/nvhe/hyp-main.c?h=linux-6.12.y#n147
That's also the case in v6.13; the earlier conversion was removed in
v6.14-rc1 in commit:
f7d03fcbf1f48206 ("KVM: arm64: Introduce __pkvm_vcpu_{load,put}()")
... where the code in the 'else' block changed from:
| ret = __kvm_vcpu_run(host_vcpu);
... to:
ret = __kvm_vcpu_run(kern_hyp_va(host_vcpu));
|
In the upstream version of this patch, the code here changed from
| /* The host is fully trusted, run its vCPU directly. */
| ret = __kvm_vcpu_run(kern_hyp_va(host_vcpu));
... to:
| struct kvm_vcpu *vcpu = kern_hyp_va(host_vcpu);
|
| /* The host is fully trusted, run its vCPU directly. */
| fpsimd_lazy_switch_to_guest(vcpu);
| ret = __kvm_vcpu_run(vcpu);
| fpsimd_lazy_switch_to_host(vcpu);
> The result is that this change is turning a perfectly valid HYP VA
> into... something. Odds are that the masking/patching will not mess up
> the address, but this is completely buggy anyway. In general,
> kern_hyp_va() is not an idempotent operation.
IIUC today it *happens* to be idempotent, but as you say that is not
guaranteed to remain the case, and this is definitely a logical bug.
> Thanks for noticing that something was wrong.
>
> Broonie, can you please look into this?
>
> Greg, it may be more prudent to unstage this series from 6.12-stable
> until we know for sure this is the only problem.
As above, likewise with the v6.13 version.
I'll go reply there linking to this thread.
Mark.
next prev parent reply other threads:[~2025-03-19 10:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 0:35 [PATCH 6.12 0/8] KVM: arm64: Backport of SVE fixes to v6.12 Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 1/8] KVM: arm64: Calculate cptr_el2 traps on activating traps Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 2/8] KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 3/8] KVM: arm64: Remove host FPSIMD saving for non-protected KVM Mark Brown
2025-03-14 5:32 ` Greg KH
2025-03-14 14:40 ` Catalin Marinas
2025-03-14 15:07 ` Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 4/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 5/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 6/8] KVM: arm64: Refactor exit handlers Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 7/8] KVM: arm64: Mark some header functions as inline Mark Brown
2025-03-14 0:35 ` [PATCH 6.12 8/8] KVM: arm64: Eagerly switch ZCR_EL{1,2} Mark Brown
2025-03-19 0:26 ` Gavin Shan
2025-03-19 9:15 ` Marc Zyngier
2025-03-19 10:20 ` Mark Rutland [this message]
2025-03-19 13:02 ` Mark Brown
2025-03-19 13:55 ` Greg Kroah-Hartman
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=Z9qaW_H9UFqdc1bI@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshan@redhat.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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