Re: [PATCH v3 2/4] LoongArch: KVM: Add PV TLB flush support via steal-time shared memory

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The KVM_FEATURE_PV_TLB_FLUSH feature is forcefully enabled by default via `pv_auto_features`, bypassing capability negotiation and breaking backward live migration.
--

commit 36054232bc9801e8c8c49df0b88a0802cdab7a98
Author: Tao Cui <cuitao@kylinos.cn>

LoongArch: KVM: Add PV TLB flush support via steal-time shared memory

This commit implements a paravirtualized TLB flush for LoongArch KVM guests
using the steal-time shared memory page. It uses the preempted byte to allow
guests to request a remote TLB flush without sending an IPI when the target
vCPU is preempted.

> diff --git a/arch/loongarch/kvm/vm.c b/arch/loongarch/kvm/vm.c
> index 8af874e0b36b2..4be70e4f1279f 100644
> --- a/arch/loongarch/kvm/vm.c
> +++ b/arch/loongarch/kvm/vm.c
[ ... ]
> @@ -54,8 +54,10 @@ static void kvm_vm_init_features(struct kvm *kvm)
>  	if (kvm_pvtime_supported()) {
>  		kvm->arch.pv_features |= BIT(KVM_FEATURE_PREEMPT);
>  		kvm->arch.pv_features |= BIT(KVM_FEATURE_STEAL_TIME);
> +		kvm->arch.pv_features |= BIT(KVM_FEATURE_PV_TLB_FLUSH);
>  		kvm->arch.kvm_features |= BIT(KVM_LOONGARCH_VM_FEAT_PV_PREEMPT);
>  		kvm->arch.kvm_features |= BIT(KVM_LOONGARCH_VM_FEAT_PV_STEALTIME);
> +		kvm->arch.kvm_features |= BIT(KVM_LOONGARCH_VM_FEAT_PV_TLB_FLUSH);
>  	}
>  	kvm->arch.pv_auto_features = kvm->arch.pv_features;
>  }

[Severity: Critical]
Does unconditionally adding KVM_FEATURE_PV_TLB_FLUSH to pv_features here
force the feature on by default, breaking capability negotiation?

Because kvm_vm_init_features() assigns pv_features to pv_auto_features, the
new PV TLB flush feature is included in the auto-enabled set. Looking at
kvm_loongarch_cpucfg_set_attr() in arch/loongarch/kvm/vcpu.c, it forces
auto-enabled features on:

    val = (val | kvm->arch.pv_auto_features) & valid;

Will this cause the source kernel to override userspace if the vmm explicitly
requests the feature to be disabled to maintain live-migration compatibility
with older hosts?

If the guest discovers and uses the feature, but migrates to an older host
that either ignores the requests or rejects the unknown feature flag, could
this result in silent memory corruption or migration failure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602021819.2373404-1-cui.tao@linux.dev?part=2