From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>,
Peter Maydell <peter.maydell@linaro.org>
Cc: Vincent Donnefort <vdonnefort@google.com>,
kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org
Subject: Re: Hang with nVHE mode and SME
Date: Wed, 26 Oct 2022 17:13:46 +0100 [thread overview]
Message-ID: <86ilk6ef5x.wl-maz@kernel.org> (raw)
In-Reply-To: <Y1lNKcXfy/nHzTQ9@sirena.org.uk>
+ Peter
On Wed, 26 Oct 2022 16:07:21 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Oct 26, 2022 at 03:29:44PM +0100, Vincent Donnefort wrote:
>
> > static void __activate_traps(struct kvm_vcpu *vcpu)
> > {
> > ...
> > if (cpus_have_final_cap(ARM64_SME)) {
> > // HANG !
>
> You're not entirely specific on where the hang is - I assume you mean
> the second SME block and that it's hanging on the first sysreg read in
> there:
>
> if (cpus_have_final_cap(ARM64_SME)) {
> u64 val;
>
> val = read_sysreg_s(SYS_HFGRTR_EL2);
>
> rather than on the if statement? A brief grep around the qemu source
> suggests that this register and fine grained traps in general are not
> implemented which is invalid with SME since this is required for SME in
> nVHE. SME is a v9.2 feature, and v9.2 includes all the requirements of
> v8.7. FEAT_FGT has been mandatory since v8.6 (where it was added).
It is very unfortunate that the SME spec doesn't call out this
explicitly, while it is calling out the dependency on FEAT_HCX (OK,
one is mandatory and the other isn't).
> I did originally have a check in there for either/both this or FEAT_HCX
> but it got taken out during review due to the architecturual
> requirement.
So the question is whether we work around this in the kernel (not
enabling either KVM or SME if FEAT_FGT is not present), or leave it as
is with the hope that QEMU gets updated.
I'm inclined to do the latter. Thoughts anyone?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-10-26 16:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 14:29 Hang with nVHE mode and SME Vincent Donnefort
2022-10-26 15:07 ` Mark Brown
2022-10-26 16:13 ` Marc Zyngier [this message]
2022-10-26 16:34 ` Mark Brown
2022-10-27 9:44 ` Peter Maydell
2022-10-27 12:01 ` Mark Brown
2022-10-27 21:16 ` Richard Henderson
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=86ilk6ef5x.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=peter.maydell@linaro.org \
--cc=vdonnefort@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 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.