Re: [PATCH v5 2/5] RISC-V: KVM: Split huge pages when dirty logging is enabled

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Silent memory attribute corruption occurs on T-Head SoCs when splitting huge pages due to pfn_pte() injecting default PMA bits.
--

--- Patch [2]: [PATCH v5 2/5] RISC-V: KVM: Split huge pages when dirty logging is enabled ---
commit 6ef4b85b2886ab213f69a407ab338186b408f754
Author: Wang Yechao <wang.yechao255@zte.com.cn>

RISC-V: KVM: Split huge pages when dirty logging is enabled

This commit splits huge pages eagerly when enabling dirty logging to avoid
doing it while faulting on write-protected pages. The benefits mirror the
eager page splitting optimizations already present in x86 and arm64.

> diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c
> index b0474fcf065aa..01679aef53289 100644
> --- a/arch/riscv/kvm/gstage.c
> +++ b/arch/riscv/kvm/gstage.c

[ ... ]

> @@ -337,27 +338,35 @@ int kvm_riscv_gstage_split_huge(struct kvm_gstage *gstage,
>  
>  		ret = gstage_level_to_page_size(gstage, current_level - 1, &child_page_size);
>  		if (ret)
> -			return ret;
> +			return need_flush;
>  
>  		next_ptep = kvm_mmu_memory_cache_alloc(pcache);
>  		if (!next_ptep)
> -			return -ENOMEM;
> +			return need_flush;
>  
>  		for (i = 0; i < PTRS_PER_PTE; i++) {
>  			child_pte = make_child_pte(huge_pte, i, child_page_size);

[Severity: High]
This isn't a bug introduced by this patch, but does this call to
make_child_pte() incur silent memory attribute corruption on T-Head SoCs?

When splitting a huge page, make_child_pte() in arch/riscv/kvm/gstage.c
adds the child PFN offset to the existing huge_pte like this:

    child_pte |= pte_val(pfn_pte(child_pfn_offset, __pgprot(0)));

On T-Head CPUs, the ALT_THEAD_PMA macro hooks into pfn_pte() and
automatically injects default PMA (Physical Memory Attribute) bits when
the provided protection value is 0.

By ORing these injected PMA bits into child_pte (which already contains
the memory attributes from huge_pte), could it create conflicting or
invalid memory types if the original huge page had different attributes
(such as IO memory)? This might cause the hardware to treat memory
mapped IO as cacheable or vice versa, potentially leading to data
corruption or hardware aborts.

>  			set_pte((pte_t *)&next_ptep[i], __pte(child_pte));
>  		}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731091215.1549430-1-wang.yechao255@zte.com.cn?part=2