Re: [PATCH v3 RESEND 5/5] RISC-V: KVM: Add the eager_page_split module parameter

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Dropping `mmu_lock` during eager page splitting without flushing the TLB allows guest writes to be silently lost from the dirty log.
--

commit 76d7c935b026714d65bf09e853c93dff6ddf2853
Author: Wang Yechao <wang.yechao255@zte.com.cn>

RISC-V: KVM: Add the eager_page_split module parameter

This commit adds an eager_page_split module parameter for RISC-V KVM.
When enabled, KVM proactively splits large pages into smaller pages for
dirty logging operations.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index cbda927dd24e3..278dd3bba680e 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c

[ ... ]

> @@ -165,8 +168,10 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
>  
>  	kvm_riscv_gstage_wp_range(&gstage, start, end);
>  
> -	if (kvm_dirty_log_manual_protect_and_init_set(kvm))
> -		mmu_split_huge_pages(&gstage, start, end);
> +	if (kvm_dirty_log_manual_protect_and_init_set(kvm)) {
> +		if (READ_ONCE(eager_page_split))
> +			mmu_split_huge_pages(&gstage, start, end);
> +	}
>  }

[Severity: Critical]
This is a pre-existing issue, but does dropping the mmu_lock here without
flushing the TLB allow guest writes to be silently lost?

In kvm_arch_mmu_enable_log_dirty_pt_masked(), kvm_riscv_gstage_wp_range()
write-protects the stage-2 page tables, but its return value is ignored,
deferring the TLB flush.

It then calls mmu_split_huge_pages(), which can drop the kvm->mmu_lock
if it needs to reschedule or top up caches:

arch/riscv/kvm/mmu.c:mmu_split_huge_pages() {
    ...
    if (need_topup_split_caches_or_resched(pcache, count)) {
        if (flush) {
            ...
        }
        write_unlock(&kvm->mmu_lock);
        cond_resched();
    ...
}

If the lock is dropped here during eager page splitting before the deferred
TLB flush happens, can guest vCPUs still write to these pages using their
stale, writable TLB entries?

Because the dirty bitmap was already cleared by the caller
kvm_clear_dirty_log_protect(), and no page fault would occur to invoke
KVM's fault handler, these writes wouldn't be recorded in the dirty log.

Would this result in silent data corruption where the destination VM
resumes with stale memory after a live migration?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624160054463wcDvJaMoydSggcNOWgcfB@zte.com.cn?part=5