Re: [PATCH v3 RESEND 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:
- [High] `need_topup_split_caches_or_resched` fails to check `rwlock_needbreak(&kvm->mmu_lock)`, causing lock starvation and latency spikes.
--

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

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

Eagerly split huge pages when enabling dirty logging to avoid faulting on
write-protected pages. This mirrors the approach taken on x86 and arm64
to improve guest performance.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 9cf69bc28b9c5..95e83c50addf5 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
[ ... ]
> +static bool need_topup_split_caches_or_resched(struct kvm_mmu_memory_cache *cache,
> +					       int count)
> +{
> +	if (need_resched())
> +		return true;
> +
> +	return kvm_mmu_memory_cache_nr_free_objects(cache) < count;
> +}
> +
> +static bool mmu_split_huge_pages(struct kvm_gstage *gstage,
> +				 phys_addr_t start, phys_addr_t end)
> +{
> +	struct kvm *kvm = gstage->kvm;
> +	struct kvm_mmu_memory_cache *pcache = &kvm->arch.pgd_split_page_cache;
> +	phys_addr_t addr = ALIGN(start, PMD_SIZE);
> +	phys_addr_t last_flush_gfn = addr >> PAGE_SHIFT;
> +	int count = gstage->pgd_levels;
> +	bool flush = false;
> +	int ret;
> +
> +	lockdep_assert_held_write(&kvm->mmu_lock);
> +
> +	while (addr < end) {
> +		if (need_topup_split_caches_or_resched(pcache, count)) {

[Severity: High]
Does this code need to check rwlock_needbreak() to avoid lock starvation?

When mmu_split_huge_pages() iterates over a memslot with kvm->mmu_lock held
in write mode, preemption is disabled. The need_resched() check alone might
not capture lock contention on kvm->mmu_lock.

If there are no huge pages to split in the memslot, the memory cache will
never deplete. This means the loop could run over large amounts of memory
without ever yielding the lock.

Could this starve other vCPUs waiting to acquire kvm->mmu_lock in read mode?
Perhaps need_topup_split_caches_or_resched() should check
rwlock_needbreak(&kvm->mmu_lock) like other architectures do during eager
page splitting?

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