From: Oliver Upton <oupton@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH] KVM: arm64: VHE: Compute fgt traps before activating them
Date: Wed, 12 Nov 2025 02:40:15 -0800 [thread overview]
Message-ID: <aRRkD8tAVcGp5zsY@kernel.org> (raw)
In-Reply-To: <20251112102853.47759-1-alexandru.elisei@arm.com>
Hi Alex,
On Wed, Nov 12, 2025 at 10:28:53AM +0000, Alexandru Elisei wrote:
> On VHE, the Fine Grain Traps registers are written to hardware in
> kvm_arch_vcpu_load()->..->__activate_traps_hfgxtr(), but the fgt array is
> computed later, in kvm_vcpu_load_fgt(). This can lead to zero being written
> to the FGT registers the first time a VCPU is loaded.
Yikes! This is no good, thank you for spotting it.
> Also, any changes to
> the fgt array will be visible only after the VCPU is scheduled out, and
> then back in, which is not the intended behaviour.
>
> Fix it by computing the fgt array just before the fgt traps are written
> to hardware.
>
> Fixes: fb10ddf35c1c ("KVM: arm64: Compute per-vCPU FGTs at vcpu_load()")
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Oliver Upton <oupton@kernel.org>
> ---
>
> Stumbled upon this when running a Linux guest on FVP with FEAT_S1PIE
> enabled. Linux touches PIRE0_EL1 very early during boot, in __cpu_setup().
> HFGWTR_EL2 was 0 the first time the VCPU was run, KVM would then trap
> the access to PIR0_EL1 (PIRE0_EL1 is an inverted trap) and trigger the
> BUG_ON(!r->access) from perform_access().
>
> I hacked __activate_traps_hfgxtr() to print the register value for
> HFGWTR_EL2. Before this patch, during the first vcpu_load(),
> HFGWTR_EL2 is 0, then it has the correct value. After this patch, it
> always has the correct value.
>
> If I were to venture a shot in the dark, it might be that the name is a bit
> misleading - it's kvm_vpcu_load_fgt(), but it doesn't load anything onto
> hardware, it just computes values. Might be worth renaming to avoid
> similar ordering issues in the future.
Ack, naming isn't quite the best here. The idea was for the name to make
it obvious that it is meant to be used at vcpu_load().
Thanks,
Oliver
next prev parent reply other threads:[~2025-11-12 10:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 10:28 [PATCH] KVM: arm64: VHE: Compute fgt traps before activating them Alexandru Elisei
2025-11-12 10:40 ` Oliver Upton [this message]
2025-11-12 10:56 ` Alexandru Elisei
2025-11-12 10:54 ` 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=aRRkD8tAVcGp5zsY@kernel.org \
--to=oupton@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--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.