15e9e35cd1
MIPS defines two kvm types: #define KVM_VM_MIPS_TE 0 #define KVM_VM_MIPS_VZ 1 In Documentation/virt/kvm/api.rst it is said that "You probably want to use 0 as machine type", which implies that type 0 be the "automatic" or "default" type. And, in user-space libvirt use the null-machine (with type 0) to detect the kvm capability, which returns "KVM not supported" on a VZ platform. I try to fix it in QEMU but it is ugly: https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg05629.html And Thomas Huth suggests me to change the definition of kvm type: https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03281.html So I define like this: #define KVM_VM_MIPS_AUTO 0 #define KVM_VM_MIPS_VZ 1 #define KVM_VM_MIPS_TE 2 Since VZ and TE cannot co-exists, using type 0 on a TE platform will still return success (so old user-space tools have no problems on new kernels); the advantage is that using type 0 on a VZ platform will not return failure. So, the only problem is "new user-space tools use type 2 on old kernels", but if we treat this as a kernel bug, we can backport this patch to old stable kernels. Signed-off-by: Huacai Chen <chenhc@lemote.com> Message-Id: <1599734031-28746-1-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> |
||
|---|---|---|
| .. | ||
| Kconfig | ||
| Makefile | ||
| callback.c | ||
| commpage.c | ||
| commpage.h | ||
| dyntrans.c | ||
| emulate.c | ||
| entry.c | ||
| fpu.S | ||
| hypcall.c | ||
| interrupt.c | ||
| interrupt.h | ||
| loongson_ipi.c | ||
| mips.c | ||
| mmu.c | ||
| msa.S | ||
| stats.c | ||
| tlb.c | ||
| trace.h | ||
| trap_emul.c | ||
| vz.c | ||