Linux KVM/arm64 development list
 help / color / mirror / Atom feed
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.

  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