On 18.03.2015 11:27, Paolo Bonzini wrote: > > > 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 > interrupt > 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 > in 3.14. > > 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. 3.14... you are optimistic. :) But thanks a lot for the detailed info. -Stefan > > Paolo >
Attachment:
signature.asc
Description: OpenPGP digital signature
