On 11/09/2020 19.22, Paolo Bonzini wrote: > On 10/09/20 12:33, Huacai Chen wrote: >> 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. > > I'm a bit wary to do that. However it's not an issue for QEMU since it > generally updates the kernel headers. Are there any other userspace programs beside QEMU that use KVM on MIPS? If there aren't any other serious userspace programs, I think we should go ahead with this patch here. Otherwise, what are the other programs that could be affected? Thomas
