Re: [PATCH 3/4] arm64: sysreg: Mark fields the architecture dropped as RES0

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] arm64/sysreg: Semantic drift in auto-generated SCTLR_EL1_RES0 mask consumed by KVM
--

commit 60f264776efd2948b9996828935b2e973ae9b2bd
Author: Fuad Tabba <fuad.tabba@linux.dev>

arm64: sysreg: Mark fields the architecture dropped as RES0

Commit d65bf6e317e7 turned the TME fields of SCTLR_EL1 into RES0, but left
their copies in SCTLRMASK_EL1. PMICFILTR_EL0.T and BRBFCR_EL1.LASTFAILED
have gone from the architecture as well, so mark them all as RES0 to match
the spec.

> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 341db8e9b6c37..99af1c39478be 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg

[ ... ]

> @@ -2663,11 +2662,7 @@ Field	57	EPAN
>  Field	56	EnALS
>  Field	55	EnAS0
>  Field	54	EnASR
> -Field	53	TME
> -Field	52	TME0
> -Field	51	TMT
> -Field	50	TMT0
> -Res0	49:47
> +Res0	53:47

[Severity: Medium]
This change reclassifies bits 53:50 of SCTLR_EL1 (TME, TME0, TMT, TMT0) from
Field to Res0. This silently regenerates the aggregate mask SCTLR_EL1_RES0 to
include these bits.

This macro is actively consumed by KVM during C initialization via
FORCE_RES0(SCTLR_EL1_RES0) in sctlr_el1_feat_map() in arch/arm64/kvm/config.c:

arch/arm64/kvm/config.c:sctlr_el1_feat_map() {
    ...
    FORCE_RES0(SCTLR_EL1_RES0),
    ...
}

Could this cause a regression in KVM guest feature configuration for SCTLR_EL1
by forcing the removed TME bits to 0? Is KVM's initialization logic robust to
SCTLR_EL1_RES0 expanding to cover bits 53:50, and is forcing these bits to 0
for guests intended?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261013130247.4135515-1-fuad.tabba@linux.dev?part=3