Re: [PATCH 6.6 v2 4/6] KVM: arm64: Initialize HCR_EL2.E2H early

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Writes to control-plane system registers are not immediately followed by an isb().
- [High] Missing `dsb` after `tlbi alle2` in `__pkvm_init_switch_pgd`.
--

--- Patch [4]: [PATCH 6.6 v2 4/6] KVM: arm64: Initialize HCR_EL2.E2H early ---
(Note: The standard inline diff formatting has been replaced with a free-form summary in this report due to code recitation restrictions.)

commit 016cd26b0c3a9694155a974c024598368716d8e4
Author: Mark Rutland <mark.rutland@arm.com>
KVM: arm64: Initialize HCR_EL2.E2H early

This patch addresses an issue where HCR_EL2.E2H might read as an UNKNOWN
value out of reset on CPUs without FEAT_E2H0 if it is not explicitly
initialized. It introduces a new 'init_el2_hcr' macro to initialize this
early in the KVM PSCI entry points so it can be reliably consumed.

Link: https://lore.kernel.org/r/20250227180526.1204723-2-mark.rutland@arm.com

[Severity: High]
This is a pre-existing issue, but in arch/arm64/kvm/hyp/nvhe/hyp-init.S and
arch/arm64/include/asm/el2_setup.h, several writes to control-plane system
registers are not immediately followed by an isb(). For example, in
___kvm_hyp_init(), writes to mair_el2 and hcr_el2 are followed by ldr and
mov instructions rather than an isb(). Similarly, in __init_el2_fgt(),
SYS_HFGRTR_EL2 and SYS_HFGWTR_EL2 are written consecutively without an
intervening isb(), and in finalise_el2_state(), writing cpacr_el1 is
followed directly by a branch. 

Since the subsystem guidelines mandate that every write to a control-plane
system register must be followed by an isb() as the very next instruction,
could this leave the CPU pipeline in an architecturally undefined state for
the intervening instructions and cause unpredictable behavior or spurious
traps during boot?

[Severity: High]
This is also a pre-existing issue, but in
arch/arm64/kvm/hyp/nvhe/hyp-init.S, __pkvm_init_switch_pgd() issues a
"tlbi alle2" instruction and subsequently installs new page tables and
re-enables the MMU without executing a dsb in between.

Because the architecture requires a dsb to guarantee the completion of a
TLB maintenance instruction, might the TLB invalidation still be pending
when the MMU is turned back on? Could this window cause the PE to fetch
instructions or data using stale TLB entries, or raise a TLB conflict
abort?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708225124.4130846-1-coltonlewis@google.com?part=4