On Thu, Mar 02, 2017 at 10:34:07PM +, James Hogan wrote:
> I suppose the exception is T It shouldn't assume that just because VZ
> is available that T 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
On 03/03/2017 13:37, James Hogan wrote:
> 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
On Thu, Mar 02, 2017 at 01:20:05PM +0100, Paolo Bonzini wrote:
> On 02/03/2017 12:39, James Hogan wrote:
> > It can't right now, though with relocation of the kernel now implemented
> > in MIPS Linux for KASLR, and hopes for a more generic EVA implementation
> > (which can require the kernel to be
Hi Paolo,
On Thu, Mar 02, 2017 at 11:59:28AM +0100, Paolo Bonzini wrote:
> On 02/03/2017 10:36, James Hogan wrote:
> > - KVM_VM_MIPS_DEFAULT = 2
> >
> >This will provide the best available KVM implementation (even on
> >older kernels), preferring hardware assisted virtualization over
On 02/03/2017 10:36, James Hogan wrote:
> - KVM_VM_MIPS_DEFAULT = 2
>
>This will provide the best available KVM implementation (even on
>older kernels), preferring hardware assisted virtualization over trap
>& emulate. The KVM_CAP_MIPS_VZ capability should always be checked
>
Add a new KVM_CAP_MIPS_VZ capability, and in order to allow MIPS KVM to
support VZ without confusing old users (which expect the trap & emulate
implementation), define and start checking KVM_CREATE_VM type codes.
The codes available are:
- KVM_VM_MIPS_TE = 0
This is the current value
