On Thu, Mar 02, 2017 at 10:34:07PM +0000, James Hogan wrote: > I suppose the exception is T&E. It shouldn't assume that just because VZ > is available that T&E isn't (even if that is the case right now). It > could always just try KVM_CREATE_VM with kvm type 0 and detect the error > I suppose, but capabilities are nicer. > > Maybe I'll redefine KVM_CAP_MIPS_VZ a bit, such that the value returned > + 1 is a bitmask of supported kvm types: > has T&E = !!( (v + 1) & BIT(KVM_VM_MIPS_TE) ) > has VZ = !!( (v + 1) & BIT(KVM_VM_MIPS_VZ) ) > > That way old kernels which return 0 are consistent, and other > implementations could be added if really necessary without confusing > userland (but fingers crossed it'll never ever be necessary). Actually I think the way I had designed KVM_CAP_MIPS_VZ is fine. I had defined it as an enumeration rather than a mask because it isn't expected you'd have more than one hardware virtualisation type able to run on a particular core. Whether T&E is still supported is I think better exposed by a new KVM_CAP_MIPS_TE capability, indicating whether T&E is exposed when KVM_CAP_MIPS_VZ is also set. It would be set to 1 on new kernels whenever T&E is supported. For compatibility with older kernels, userland would be expected to determine whether T&E is present by: check(KVM_CAP_MIPS_VZ) == 0 || check(KVM_CAP_MIPS_TE) != 0 Old userland that doesn't check KVM_CAP_MIPS_TE would just hit an EINVAL from KVM_CREATE_VM if T&E isn't supported. Cheers James
Attachment:
signature.asc
Description: Digital signature
