From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Nested kvm_intel broken on pre 3.3 hosts Date: Wed, 01 Aug 2012 18:11:24 +0300 Message-ID: <5019471C.6050907@redhat.com> References: <50191307.5030107@canonical.com> <20120801133940.GB27579@redhat.com> <50193875.3090200@redhat.com> <50193C94.1030809@canonical.com> <50193D3E.9090100@redhat.com> <20120801150707.GA3688@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Bader , Gleb Natapov , kvm@vger.kernel.org, Andy Whitcroft To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21419 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754602Ab2HAPLb (ORCPT ); Wed, 1 Aug 2012 11:11:31 -0400 In-Reply-To: <20120801150707.GA3688@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 08/01/2012 06:07 PM, Nadav Har'El wrote: > On Wed, Aug 01, 2012, Avi Kivity wrote about "Re: Nested kvm_intel broken on pre 3.3 hosts": >> Right - it's not just kvm-as-a-guest that will trip on this. But >> there's no point in everyone backporting it on their own. If you're >> doing the backport, please post it here and we'll forward it to the >> stable branch. > > If I understand correctly, the failure occurs because new versions of > KVM refuse to work if the processor doesn't support CPU_BASED_RDPMC_EXITING - > which older versions of nested VMX didn't say that they did. Right. > But must the KVM guest refuse to work if this feature isn't supported? > I.e., why not move in setup_vmcs_config() the CPU_BASED_RDPMC_EXITING > from "min" to "opt"? Isn't losing the PMU feature a lesser evil than > not working at all? In any case, perhaps the original reporter can use > this as a workaround, at least, because it requires modifying the (L1) > guest, not the host. Real processors that don't support RDPMC exiting don't exist (and logically cannot exist unless they also drop support for the RDPMC instruction). Given it's a clear host bug I'd rather fix it than making the guest more complicated, even by a small amount. The hypervisor needs to be updated on a regular schedule anyway, so there's no risk of locking users out for more than a short while. -- error compiling committee.c: too many arguments to function