Re: [PATCH v3 02/11] arm64/cpufeature: Add system-wide FEAT_HACDBS detection

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Missing KVM ID register filtering exposes FEAT_HACDBS to guests, preventing VMMs from hiding the feature and breaking VM migration.
- [Low] The new capability HACDBS is not alphabetically sorted in the cpucaps list.
--

--- Patch [2]: [PATCH v3 02/11] arm64/cpufeature: Add system-wide FEAT_HACDBS detection ---
commit 79552fba5f033b2becee395a64d0ccf3fbde7b1a
Author: Leonardo Bras <leo.bras@arm.com>

arm64/cpufeature: Add system-wide FEAT_HACDBS detection

This commit adds system-wide CPU feature detection for FEAT_HACDBS
(Hardware dirty bit Cleaning). It updates the cpufeature structures
and cpucaps list to track the feature across the system.

> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index aa327eebaf1ca..62f56bbd0a65c 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -523,6 +523,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr3[] = {
>  static const struct arm64_ftr_bits ftr_id_aa64mmfr4[] = {
>  	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_E2H0_SHIFT, 4, 0),
>  	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_NV_frac_SHIFT, 4, 0),
> +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_HACDBS_SHIFT, 4, 0),

[Severity: Critical]
Does exposing this feature here break VM live migration for KVM?

By adding HACDBS to the host's sanitised ID register, it is subsequently
read by KVM to form the guest's ID register limit.

Looking at arch/arm64/kvm/sys_regs.c:__kvm_read_sanitised_id_reg(), there is
no case handling SYS_ID_AA64MMFR4_EL1, which means the host's HACDBS value
unconditionally leaks into the guest's limit.

Furthermore, looking at sys_reg_descs in arch/arm64/kvm/sys_regs.c:

	ID_WRITABLE(ID_AA64MMFR4_EL1, ID_AA64MMFR4_EL1_NV_frac),

The writable mask for ID_AA64MMFR4_EL1 does not include HACDBS. Because KVM
strictly enforces that non-writable fields must match the destination host's
limit, a VMM attempting to restore a saved VM state will fail if the source
and destination hosts have different HACDBS support.

Could this be addressed by either masking HACDBS from the guest view or
making the field writable by the VMM?

>  	ARM64_FTR_END,
>  };

[ ... ]

> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> index a87706c9d160e..bd2c0bb98da61 100644
> --- a/arch/arm64/tools/cpucaps
> +++ b/arch/arm64/tools/cpucaps
> @@ -72,6 +72,7 @@ HAS_XNX
>  HAS_HDBSS
>  HAFT
>  HW_DBM
> +HACDBS

[Severity: Low]
This isn't a bug, but HACDBS is inserted out of alphabetical order here.

Does this violate the "# Internal CPU capabilities constants, keep this list
sorted" comment at the top of the arch/arm64/tools/cpucaps file?

>  KVM_HVHE
>  KVM_PROTECTED_MODE
>  MISMATCHED_CACHE_TYPE

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729104548.3439958-1-leo.bras@arm.com?part=2