Re: [PATCH v4 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:
- [High] Lost dirty tracking bits when yielding `mmu_lock` during eager page splitting.
--

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

RISC-V: KVM: Add the eager_page_split module parameter

This patch adds an eager_page_split module parameter for RISC-V KVM, following
the same approach as on x86. It controls whether eager page splitting is
enabled during dirty logging. Disabling it can benefit VM workloads that
rarely perform writes by keeping huge pages intact.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 29a7ac023d4db..a534f596c8ca0 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c

[ ... ]

> @@ -167,8 +170,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: High]
This is a pre-existing issue, but since we're modifying this path, could this
lead to lost dirty tracking bits?

In kvm_arch_mmu_enable_log_dirty_pt_masked(), kvm_riscv_gstage_wp_range()
write-protects the page tables and returns a boolean indicating if a TLB
flush is needed, but this return value is currently ignored.

When mmu_split_huge_pages() is called immediately after, it can drop the
mmu_lock and yield:

arch/riscv/kvm/mmu.c:mmu_split_huge_pages() {
    ...
    if (need_topup_split_caches_or_resched(kvm, count)) {
        if (flush) {
            ...
        }

        write_unlock(&kvm->mmu_lock);
        cond_resched();
    ...
}

If the lock is dropped without flushing the TLBs for the newly
write-protected pages, couldn't guest vCPUs continue executing and write
to these pages without taking a page fault?

This seems like it would allow the hardware to use stale writable TLB entries
while KVM has already cleared its software dirty bitmap, potentially leading
to silent memory corruption during live migration.

Should we ensure the TLBs are flushed for the write-protected range before
yielding the mmu_lock?

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