Re: [PATCH 11/32] KVM: MIPS: Add VZ capability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux