Re: [PATCH v4 1/6] KVM: arm64: Enable eager hugepage splitting if HDBSS is available

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The default eager page splitting chunk size evaluates to an architecturally invalid block size on 16KB and 64KB page systems and suffers from integer truncation in KVM_CHECK_EXTENSION.
- [Medium] The global capability query for eager page splitting chunk size incorrectly reports the default as 0 (disabled) when HDBSS is present.
--

--- Patch [1]: [PATCH v4 1/6] KVM: arm64: Enable eager hugepage splitting if HDBSS is available ---
commit 382048a591b4a06f749e61447083eb8630f1bad5
Author: Leonardo Bras <leo.bras@arm.com>
Subject: KVM: arm64: Enable eager hugepage splitting if HDBSS is available

This commit enables eager hugepage splitting by default at stage2
initialization when the system supports HDBSS. It sets the chunk size
to 256K * PAGE_SIZE.

> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 6c941aaa10c63..e086c01a9325e 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1027,8 +1027,12 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
>  	for_each_possible_cpu(cpu)
>  		*per_cpu_ptr(mmu->last_vcpu_ran, cpu) = -1;
>  
> -	 /* The eager page splitting is disabled by default */
> -	mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
> +	 /* The eager page splitting is disabled by default if system has no HDBSS */
> +	if (system_supports_hdbss())
> +		mmu->split_page_chunk_size = 256 * 1024 * PAGE_SIZE;

[Severity: High]
Does this chunk size assignment create architecturally invalid block sizes
on 16KB and 64KB page systems?

On 16KB and 64KB systems, 256 * 1024 * PAGE_SIZE evaluates to 4GB and
16GB respectively. Since level 1 blocks are not supported for these
page sizes on ARM64, this exceeds the valid maximums (32MB and 512MB).
If a VMM attempts to restore this configuration, kvm_vm_ioctl_enable_cap()
in arch/arm64/kvm/arm.c will reject it via kvm_is_block_size_supported(),
which breaks live migration.

Additionally, can this cause integer truncation during capability queries?

In arch/arm64/kvm/arm.c:kvm_vm_ioctl_check_extension(), the 64-bit chunk
size is assigned to a 32-bit signed integer. The values 4GB (0x100000000)
and 16GB (0x400000000) will truncate to 0. A VMM querying this capability
would read 0 and restore 0 on the destination, silently disabling the
feature.

[Severity: Medium]
Does this new dynamic default desync with the global capability query?

When userspace queries /dev/kvm via KVM_CHECK_EXTENSION for
KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE without a VM instance,
arch/arm64/kvm/arm.c:kvm_vm_ioctl_check_extension() unconditionally returns
KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT (0).

Since this patch changes the default dynamically for new VMs based on
system_supports_hdbss(), the global API query now misleads userspace about
the default capability.

> +	else
> +		mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
> +
>  	mmu->split_page_cache.gfp_zero = __GFP_ZERO;
>  
>  	mmu->pgd_phys = __pa(pgt->pgd);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709104026.2612599-1-zhengtian10@huawei.com?part=1