Re: [PATCH] riscv: KVM: Flush VS-stage stale entries

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

New issues:
- [High] Direct execution of the raw HFENCE.VVMA instruction in kvm_riscv_m=
mu_update_hgatp() bypasses the Nested Acceleration (NACL) shared memory mec=
hanism, breaking nested virtualization.

Pre-existing issues:
- [Critical] The VS-stage TLB flush condition `last_exit_cpu !=3D cpu` is i=
ncomplete, skipping necessary flushes during VMID rollover, `vmid_bits =3D=
=3D 0` configurations, and same-VM vCPU interleaving on the same physical C=
PU.
--

--- Patch [1]: [PATCH] riscv: KVM: Flush VS-stage stale entries ---
commit f1e080e98f0df465d2cf4d51c2026f9bf9cd7c71
Author: Guo Ren (Alibaba DAMO Academy) <[email protected]>

riscv: KVM: Flush VS-stage stale entries

When a vCPU migrates to a different host CPU, the new CPU may retain
stale VS-stage TLB entries (GVA -> GPA) left by a previous run of the
same guest. This patch issues an HFENCE.VVMA inside
kvm_riscv_mmu_update_hgatp() whenever the vCPU is loaded on a CPU
different from the one it last exited on.

> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 8a0aa5e0e216e..8eae1805442ba 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
> @@ -719,4 +719,7 @@ void kvm_riscv_mmu_update_hgatp(struct kvm_vcpu *vcpu)
> =20
>  	if (!kvm_riscv_gstage_vmid_bits())
>  		kvm_riscv_local_hfence_gvma_all();
> +
> +	if (vcpu->arch.last_exit_cpu !=3D cpu)

[Severity: Critical]
This is a pre-existing issue, but does this condition properly flush VS-sta=
ge
TLB entries during VMID rollover, configurations where vmid_bits is 0, or w=
hen
interleaving different VMs on the same physical CPU?

If a vCPU switches VMs on the same physical CPU, last_exit_cpu will still
equal cpu and skip the flush. Since HFENCE.GVMA issued during rollover or VM
switch does not guarantee flushing of VS-stage entries, could the incoming
vCPU inherit the previous VM's stale VS-stage mappings?

> +		asm volatile(HFENCE_VVMA(zero, zero) : : : "memory");

[Severity: High]
Does executing the raw HFENCE.VVMA instruction bypass the Nested Accelerati=
on
(NACL) shared memory mechanism?

When executing as an L1 guest with NACL enabled, ncsr_write(CSR_HGATP, hgat=
p)
only updates KVM's shared memory page with L0, not the physical CSR. Since =
the
direct HFENCE.VVMA instruction is executed immediately after on the physical
core, does it flush the TLB using the old (stale) VMID still present in the
physical CSR?

Additionally, if no flush request is enqueued into the NACL shared memory v=
ia
nacl_hfence_vvma_all(), will the L0 hypervisor fail to perform the flush for
the new VMID before switching to the L2 guest?

>  }

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803135454.2726=
[email protected]?part=3D1