Re: [PATCH v5 2/2] RISC-V: KVM: Recover gstage huge page mappings during disable-dirty-log

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Reconstructing huge pages leaves stale 4K TLB entries, which can cause infinite page fault loops.
--

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

RISC-V: KVM: Recover gstage huge page mappings during disable-dirty-log

This commit recovers gstage huge page mappings when dirty logging is disabled.
It is intended to restore vm performance to pre-dirty-logging levels if a
migration fails or is canceled.

> diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c
> index e5002cb9cbef1..2bbe052b97806 100644
> --- a/arch/riscv/kvm/gstage.c
> +++ b/arch/riscv/kvm/gstage.c
[ ... ]
> +bool kvm_riscv_gstage_recover_huge(struct kvm_gstage *gstage, gpa_t addr,
> +				   unsigned long target_page_size,
> +				   unsigned long *page_size)
> +{
[ ... ]
> +	for (i = 0; i < PTRS_PER_PTE; i++) {
> +		child_ptep = (pte_t *)&next_ptep[i];
> +		if (!gstage_pte_leaf(child_ptep))
> +			continue;
> +
> +		huge_pte = make_huge_pte(pte_val(ptep_get(child_ptep)),
> +					 i, target_page_size / PTRS_PER_PTE);
> +		set_pte(ptep, __pte(huge_pte));
> +		gstage_tlb_flush(gstage, target_level, addr);

[Severity: High]
Does this tlb flush leave stale 4KB entries in the hardware tlb?

When dirty logging is enabled, a 2MB huge page is split into 4KB read-only
pages. If dirty logging is then disabled and kvm reconstructs the 2MB huge
page by replacing the non-leaf pte with a 2MB leaf pte, this code calls
gstage_tlb_flush() for the target level.

This passes the huge page order to kvm_riscv_local_hfence_gvma_vmid_gpa(),
which executes a single hfence.gvma instruction for the 2MB-aligned base
address. Because hfence.gvma with a specific address only invalidates
translations matching exactly that address, could the 4KB tlb entries for
sub-pages (like addr + 4KB) remain cached in the hardware tlb?

If the guest attempts to write to one of these stale 4KB pages, it triggers
a guest store page fault. The kvm page fault handler checks the gstage page
tables, observes the new 2MB pte is already writable, issues no tlb flush,
and returns to the guest. Would the guest then retry the write instruction,
hit the same stale read-only 4KB tlb entry, and fault again, creating an
infinite loop?

> +		put_page(virt_to_page(next_ptep));
> +		recovered = true;
> +
> +		break;
> +	}

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