From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755808AbbCRK1K (ORCPT ); Wed, 18 Mar 2015 06:27:10 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:33273 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753123AbbCRK1H (ORCPT ); Wed, 18 Mar 2015 06:27:07 -0400 Message-ID: <550952F5.7060702@redhat.com> Date: Wed, 18 Mar 2015 11:27:01 +0100 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stefan Bader , kvm@vger.kernel.org, Linux Kernel Mailing List Subject: Re: regression: nested: L1 3.15+ fails to load kvm-intel on L0 <3.15 References: <55093B52.5090904@canonical.com> <550942ED.4040809@redhat.com> <55094C73.4000608@canonical.com> In-Reply-To: <55094C73.4000608@canonical.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Paolo