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 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? Cheers James
Attachment:
signature.asc
Description: Digital signature
