Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15
From: Paolo Bonzini
Date: Wed Mar 18 2015 - 06:27:14 EST
On 18/03/2015 10:59, Stefan Bader wrote:
>> @@ -2850,7 +2851,7 @@ static __init int setup_vmcs_config(struct
>> vmcs_config *vmcs_conf) vmx_capability.ept,
>> vmx_capability.vpid); }
>> - min = 0; + min = VM_EXIT_SAVE_DEBUG_CONTROLS; #ifdef
>> CONFIG_X86_64 min |= VM_EXIT_HOST_ADDR_SPACE_SIZE; #endif
>> but I don't think it's a good idea to add it to stable kernels.
> Why is that? Because it has a risk of causing the module failing to
> load on L0 where it did work before?
Because if we wanted to make 3.14 nested VMX stable-ish we would need
several more, at least these:
KVM: nVMX: fix lifetime issues for vmcs02
KVM: nVMX: clean up nested_release_vmcs12 and code around it
KVM: nVMX: Rework interception of IRQs and NMIs
KVM: nVMX: Do not inject NMI vmexits when L2 has a pending
KVM: nVMX: Disable preemption while reading from shadow VMCS
and for 3.13:
KVM: nVMX: Leave VMX mode on clearing of feature control MSR
There are also several L2-crash-L1 bugs too in Nadav Amit's patches.
Basically, nested VMX was never considered stable-worthy. Perhaps
that can change soon---but not retroactively.
So I'd rather avoid giving false impressions of the stability of nVMX
Even if we considered nVMX stable, I'd _really_ not want to consider
the L1<->L2 boundary a secure one for a longer time.
> Which would be something I would rather avoid. Generally I think it
> would be good to have something that can be generally applied.
> Given the speed that cloud service providers tend to move forward
> (ok they may not actively push the ability to go nested).
And if they did, I'd really not want them to do it with a 3.14 kernel.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/