From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
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>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v2 07/13] KVM: arm64: nv: Honor HFGITR_EL2.ERET being set
Date: Fri, 01 Mar 2024 19:14:00 +0000 [thread overview]
Message-ID: <861q8t3guf.wl-maz@kernel.org> (raw)
In-Reply-To: <20240301180734.GA3958355@e124191.cambridge.arm.com>
Hi Joey,
On Fri, 01 Mar 2024 18:07:34 +0000,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> Got a question about this one,
>
> On Mon, Feb 26, 2024 at 10:05:55AM +0000, Marc Zyngier wrote:
> > If the L1 hypervisor decides to trap ERETs while running L2,
> > make sure we don't try to emulate it, just like we wouldn't
> > if it had its NV bit set.
> >
> > The exception will be reinjected from the core handler.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/hyp/vhe/switch.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > index eaf242b8e0cf..3ea9bdf6b555 100644
> > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > @@ -220,7 +220,8 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code)
> > * Unless the trap has to be forwarded further down the line,
> > * of course...
> > */
> > - if (__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV)
> > + if ((__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV) ||
> > + (__vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET))
> > return false;
> >
> > spsr = read_sysreg_el1(SYS_SPSR);
>
> Are we missing a forward_traps() call in kvm_emulated_nested_eret() for the
> HFGITR case?
>
> Trying to follow the code path here, and I'm unsure of where else the
> HFIGTR_EL2_ERET trap would be forwarded:
>
> kvm_arm_vcpu_enter_exit ->
> ERET executes in guest
> fixup_guest_exit ->
> kvm_hyp_handle_eret (returns false)
>
> handle_exit ->
> kvm_handle_eret ->
> kvm_emulated_nested_eret
> if HCR_NV
> forward traps
> else
> emulate ERET
There's a bit more happening in kvm_handle_eret().
>
>
> And if the answer is that it is being reinjected somewhere, putting that
> function name in the commit instead of 'core handler' would help with
> understanding!
Let's look at the code:
static int kvm_handle_eret(struct kvm_vcpu *vcpu)
{
[...]
if (is_hyp_ctxt(vcpu))
kvm_emulate_nested_eret(vcpu);
If we're doing an ERET from guest EL2, then we just emulate it,
because there is nothing else to do. Crucially, HFGITR_EL2.ERET
doesn't apply to EL2.
else
kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
In any other case, we simply reinject the trap into the guest EL2,
because that's the only possible outcome. And that's what you were
missing.
return 1;
}
> I need to find the time to get an NV setup set-up, so I can do some experiments
> myself.
The FVP should be a good enough environment if you can bare the
glacial speed. Other than that, I hear that QEMU has grown some NV
support lately, but I haven't tried it yet. HW-wise, M2 is the only
machine that can be bought by a human being (everything else is
vapourware, or they would have already taken my money).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
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>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH v2 07/13] KVM: arm64: nv: Honor HFGITR_EL2.ERET being set
Date: Fri, 01 Mar 2024 19:14:00 +0000 [thread overview]
Message-ID: <861q8t3guf.wl-maz@kernel.org> (raw)
In-Reply-To: <20240301180734.GA3958355@e124191.cambridge.arm.com>
Hi Joey,
On Fri, 01 Mar 2024 18:07:34 +0000,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> Got a question about this one,
>
> On Mon, Feb 26, 2024 at 10:05:55AM +0000, Marc Zyngier wrote:
> > If the L1 hypervisor decides to trap ERETs while running L2,
> > make sure we don't try to emulate it, just like we wouldn't
> > if it had its NV bit set.
> >
> > The exception will be reinjected from the core handler.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/hyp/vhe/switch.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > index eaf242b8e0cf..3ea9bdf6b555 100644
> > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > @@ -220,7 +220,8 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code)
> > * Unless the trap has to be forwarded further down the line,
> > * of course...
> > */
> > - if (__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV)
> > + if ((__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV) ||
> > + (__vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET))
> > return false;
> >
> > spsr = read_sysreg_el1(SYS_SPSR);
>
> Are we missing a forward_traps() call in kvm_emulated_nested_eret() for the
> HFGITR case?
>
> Trying to follow the code path here, and I'm unsure of where else the
> HFIGTR_EL2_ERET trap would be forwarded:
>
> kvm_arm_vcpu_enter_exit ->
> ERET executes in guest
> fixup_guest_exit ->
> kvm_hyp_handle_eret (returns false)
>
> handle_exit ->
> kvm_handle_eret ->
> kvm_emulated_nested_eret
> if HCR_NV
> forward traps
> else
> emulate ERET
There's a bit more happening in kvm_handle_eret().
>
>
> And if the answer is that it is being reinjected somewhere, putting that
> function name in the commit instead of 'core handler' would help with
> understanding!
Let's look at the code:
static int kvm_handle_eret(struct kvm_vcpu *vcpu)
{
[...]
if (is_hyp_ctxt(vcpu))
kvm_emulate_nested_eret(vcpu);
If we're doing an ERET from guest EL2, then we just emulate it,
because there is nothing else to do. Crucially, HFGITR_EL2.ERET
doesn't apply to EL2.
else
kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
In any other case, we simply reinject the trap into the guest EL2,
because that's the only possible outcome. And that's what you were
missing.
return 1;
}
> I need to find the time to get an NV setup set-up, so I can do some experiments
> myself.
The FVP should be a good enough environment if you can bare the
glacial speed. Other than that, I hear that QEMU has grown some NV
support lately, but I haven't tried it yet. HW-wise, M2 is the only
machine that can be bought by a human being (everything else is
vapourware, or they would have already taken my money).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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:[~2024-03-01 19:14 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 10:05 [PATCH v2 00/13] KVM/arm64: Add NV support for ERET and PAuth Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 01/13] KVM: arm64: Harden __ctxt_sys_reg() against out-of-range values Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 02/13] KVM: arm64: Add helpers for ESR_ELx_ERET_ISS_ERET* Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 03/13] KVM: arm64: nv: Drop VCPU_HYP_CONTEXT flag Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 04/13] KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2 Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 05/13] KVM: arm64: nv: Add trap forwarding for ERET and SMC Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 06/13] KVM: arm64: nv: Fast-track 'InHost' exception returns Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-28 16:08 ` Joey Gouly
2024-02-28 16:08 ` Joey Gouly
2024-02-29 13:44 ` Marc Zyngier
2024-02-29 13:44 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 07/13] KVM: arm64: nv: Honor HFGITR_EL2.ERET being set Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-03-01 18:07 ` Joey Gouly
2024-03-01 18:07 ` Joey Gouly
2024-03-01 19:14 ` Marc Zyngier [this message]
2024-03-01 19:14 ` Marc Zyngier
2024-03-01 20:15 ` Joey Gouly
2024-03-01 20:15 ` Joey Gouly
2024-02-26 10:05 ` [PATCH v2 08/13] KVM: arm64: nv: Handle HCR_EL2.{API,APK} independently Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-03-07 15:14 ` Joey Gouly
2024-03-07 15:14 ` Joey Gouly
2024-03-07 15:58 ` Marc Zyngier
2024-03-07 15:58 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 09/13] KVM: arm64: nv: Reinject PAC exceptions caused by HCR_EL2.API==0 Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 10/13] KVM: arm64: nv: Add kvm_has_pauth() helper Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-02-26 10:05 ` [PATCH v2 11/13] KVM: arm64: nv: Add emulation for ERETAx instructions Marc Zyngier
2024-02-26 10:05 ` Marc Zyngier
2024-03-07 13:39 ` Joey Gouly
2024-03-07 13:39 ` Joey Gouly
2024-03-07 14:24 ` Marc Zyngier
2024-03-07 14:24 ` Marc Zyngier
2024-03-08 17:20 ` Joey Gouly
2024-03-08 17:20 ` Joey Gouly
2024-03-08 17:54 ` Marc Zyngier
2024-03-08 17:54 ` Marc Zyngier
2024-03-12 10:46 ` Joey Gouly
2024-03-12 10:46 ` Joey Gouly
2024-02-26 10:06 ` [PATCH v2 12/13] KVM: arm64: nv: Handle ERETA[AB] instructions Marc Zyngier
2024-02-26 10:06 ` Marc Zyngier
2024-03-12 11:17 ` Joey Gouly
2024-03-12 11:17 ` Joey Gouly
2024-02-26 10:06 ` [PATCH v2 13/13] KVM: arm64: nv: Advertise support for PAuth Marc Zyngier
2024-02-26 10:06 ` Marc Zyngier
2024-03-12 11:21 ` Joey Gouly
2024-03-12 11:21 ` Joey Gouly
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=861q8t3guf.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--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.