From: Marc Zyngier <maz@kernel.org>
To: Jan Kotas <jank@cadence.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>
Subject: Re: KVM NV + SVE host OS warning
Date: Wed, 08 Oct 2025 16:22:31 +0100 [thread overview]
Message-ID: <86y0plxvt4.wl-maz@kernel.org> (raw)
In-Reply-To: <15A85F2B-1A0C-4FA7-9FE4-EEC2203CC09E@global.cadence.com>
On Wed, 08 Oct 2025 14:43:29 +0100,
Jan Kotas <jank@cadence.com> wrote:
> >>
> >> Is it possible to trap/emulate HCR_EL2, and make sure E2H is always 1,
> >> in cases when only KVM_ARM_VCPU_HAS_EL2 is set?
> >> Would that help?
> >
> > There are no traps for HCR_EL2.
> >
> >> As a test, I tried forcing this bit before running VCPUs, but
> >> reading it via MRS got a value without it being set.
> >
> > Where did you read that from?
>
> I checked the X1 register, after: mrs x1, hcr_el2 in __check_hvhe.
That's too late. At this point, the write to HCR_EL2 will have already
occurred,
>
>
> > If you apply the following change to your guest, does it start
> > behaving?
> >
> > M.
> >
> > diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
> > index 46033027510cc..392c9f4016f2e 100644
> > --- a/arch/arm64/include/asm/el2_setup.h
> > +++ b/arch/arm64/include/asm/el2_setup.h
> > @@ -34,7 +34,7 @@
> > mrs_s x1, SYS_ID_AA64MMFR4_EL1
> > sbfx x1, x1, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
> > cmp x1, #0
> > - b.ge .LnVHE_\@
> > +// b.ge .LnVHE_\@
> >
> > orr x0, x0, #HCR_E2H
> > .LnVHE_\@:
> >
>
> With this change Guest OS starts the boot process.
>
> [ 0.000000] CPU features: detected: Virtualization Host Extensions
> [ 6.998696] SMP: Total of 4 processors activated.
> [ 7.257045] CPU: All CPU(s) started at EL2
> [ 185.781062] SVE: maximum available vector length 16 bytes per vector
> [ 186.104159] SVE: default vector length 16 bytes per vector
Great. That confirms my suspicion that we cannot advertise VHE on CPUs
that do not have FEAT_FGT. Oh well. I'll post a patch to forbid VHE
guests on these machines.
> I also observed something interesting.
> When PSCI method is set to HVC, I get a kernel panic.
> This wasn’t a problem in all other test cases.
Well, that's completely expected. HVC is handled by EL2. You run at
EL2. You end-up calling yourself, which you don't really expect.
SMC is the way for EL2 guests, as if they were on bare-metal.
> On a side note, thank you for giving me some pointers.
> With HAS_EL2_E2H the original Guest OS boots fine in nVHE.
>
> [ 0.204744] CPU: All CPU(s) started at EL2
> [ 18.483737] SVE: maximum available vector length 16 bytes per vector
> [ 18.500959] SVE: default vector length 16 bytes per vector
> [ 25.999475] kvm [1]: Hyp nVHE mode initialized successfully
Yup. I'll kill the ability to run VHE guests on crappy old HW then.
Thanks for giving it a go!
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-10-08 15:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <799DD5E5-8BC2-47B3-A919-33429D3FB2F1@global.cadence.com>
2025-09-25 14:38 ` KVM NV + SVE host OS warning Marc Zyngier
2025-09-25 15:10 ` Jan Kotas
2025-09-25 15:35 ` Marc Zyngier
2025-09-25 22:46 ` Oliver Upton
2025-10-07 11:12 ` Jan Kotas
2025-10-07 23:26 ` Oliver Upton
2025-10-08 6:32 ` Jan Kotas
2025-10-08 7:29 ` Jan Kotas
2025-10-08 9:28 ` Marc Zyngier
2025-10-08 9:45 ` Jan Kotas
2025-10-08 11:58 ` Marc Zyngier
2025-10-08 13:43 ` Jan Kotas
2025-10-08 15:22 ` Marc Zyngier [this message]
2025-10-09 10:59 ` Jan Kotas
2025-10-09 12:22 ` Marc Zyngier
2025-10-09 14:41 ` Jan Kotas
2025-10-09 15:01 ` Marc Zyngier
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=86y0plxvt4.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=jank@cadence.com \
--cc=kvmarm@lists.linux.dev \
--cc=oliver.upton@linux.dev \
/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