在2024年7月1日七月 上午8:32，maobibo写道：
[...]
+static void loongarch_cpu_check_lbt(CPUState *cs, Error **errp)
+{
+ CPULoongArchState *env = cpu_env(cs);
+ LoongArchCPU *cpu = LOONGARCH_CPU(cs);
+ bool kvm_supported;
+
+ kvm_supported = kvm_feature_supported(cs, LOONGARCH_FEATURE_LBT);
IMHO if there is no global states that should be saved/restored VM wise,
this should be handled at per CPU level, preferably with CPUCFG flags hint.
We should minimize non-privilege KVM feature bits to prevent hindering
asymmetry ISA system.
For "asymmetry ISA system", do you meaning some vcpus have LBT feature,
however some vcpus does have LBT features? That does not exists at all.
Yes, we should always prepare for the future :-)
From Weiwu's presentations, I believe LASX asymmetry product is already on the
roadmap. So for LBT it's also a possibility.
Even if such product won't land in near future, we should still try our best
to bound to vCPU creation, not to the system.
It will be big disaster for such products, how does application use this?
Affinity placement etc, there are many possibilities.
On Arm side, there are already systems with Big.Little asymmetry CPU that
some of the processor equipped 32 bit EL0 mode while others doesn't. They
managed that well with affinity.
See: arm64: Allow mismatched 32-bit EL0 support