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

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

 




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

Attachment: signature.asc
Description: OpenPGP 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