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