All of lore.kernel.org
 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 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.