[Top] [All Lists]

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

To: Paolo Bonzini <>
Subject: Re: [PATCH 11/32] KVM: MIPS: Add VZ capability
From: James Hogan <>
Date: Thu, 2 Mar 2017 11:39:23 +0000
Cc: <>, <>, Radim Krčmář <>, Ralf Baechle <>, Jonathan Corbet <>, <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <>
User-agent: Mutt/1.5.24 (2015-08-30)
Hi Paolo,

On Thu, Mar 02, 2017 at 11:59:28AM +0100, Paolo Bonzini wrote:
> On 02/03/2017 10:36, James Hogan wrote:
> > 
> >    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
> >    against known values to determine what type of implementation was
> >    chosen.
> > 
> > This is designed to allow the desired implementation (T&E vs VZ) to be
> > potentially chosen at runtime rather than being fixed in the kernel
> > configuration.
> Can the same kernel run on both TE and VZ?  If not, I'm not sure that
> KVM_VM_MIPS_DEFAULT is a good idea.

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 linked in a completely different
segment) it isn't completely infeasible.

Currently the two uses of this I've implemented are:

1) QEMU, which I've implemented using the kvm_type machine callback.
This allows the KVM type to be specified with e.g.
  "-machine malta,accel=kvm,kvm-type=TE"
Otherwise it defaults to using KVM_VM_MIPS_DEFAULT.

When you try and load a kernel (which happens after kvm_init() has
already passed the kvm type into KVM_CREATE_VM) it will check that it
supports the current kernel type.

2) My kvm test application, which uses KVM_VM_MIPS_DEFAULT by default
and hackily maps itself into the guest physical address space to run C
code test cases.

Does that justification sound reasonable?


Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>