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 linked in a completely different > segment) it isn't completely infeasible.
What about the other way round, sticking a minimal T&E stub in kernel space and running the kernel in userspace? Would it be feasible or would it be as complex as KVM itself? > 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. So this one would work for both TE and VZ because the guest is not a Linux kernel. I don't know... Instinctively I would think that it's easy to get KVM_VM_MIPS_DEFAULT wrong and place the VZ-and-fall-back-to-TE policy in userspace, but I can be convinced otherwise if the failure mode is good enough. For example, what happens if you use KVM_SET_USER_MEMORY_REGION for a kernel address in TE mode? Paolo
signature.asc
Description: OpenPGP digital signature
