From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755702AbcFQRPV (ORCPT ); Fri, 17 Jun 2016 13:15:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60870 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751690AbcFQRPT (ORCPT ); Fri, 17 Jun 2016 13:15:19 -0400 Date: Fri, 17 Jun 2016 14:15:15 -0300 From: Eduardo Habkost To: Paolo Bonzini , kvm@vger.kernel.org, rkrcmar@redhat.com, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Gleb Natapov , Boris Petkov , Tony Luck , Andi Kleen , Ashok Raj , libvir-list@redhat.com, Jiri Denemark Subject: Re: [PATCH v2 3/3] KVM: VMX: enable guest access to LMCE related MSRs Message-ID: <20160617171515.GJ18662@thinpad.lan.raisama.net> References: <20160616060531.30028-1-haozhong.zhang@intel.com> <20160616060531.30028-4-haozhong.zhang@intel.com> <1785f481-033b-2780-37b8-d27f80276d33@redhat.com> <20160616145546.GJ18662@thinpad.lan.raisama.net> <20160617011116.7k7e2zmkwhfvajla@hz-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160617011116.7k7e2zmkwhfvajla@hz-desktop> X-Fnord: you can see the fnord User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 17 Jun 2016 17:15:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 17, 2016 at 09:11:16AM +0800, Haozhong Zhang wrote: > On 06/16/16 11:55, Eduardo Habkost wrote: > > On Thu, Jun 16, 2016 at 12:04:50PM +0200, Paolo Bonzini wrote: > > > On 16/06/2016 08:05, Haozhong Zhang wrote: > > > > From: Ashok Raj > > > > > > > > On Intel platforms, this patch adds LMCE to KVM MCE supported > > > > capabilities and handles guest access to LMCE related MSRs. > > > > > > > > Signed-off-by: Ashok Raj > > > > [Haozhong: macro KVM_MCE_CAP_SUPPORTED => variable kvm_mce_cap_supported > > > > Only enable LMCE on Intel platform > > > > Check MSR_IA32_FEATURE_CONTROL when handling guest > > > > access to MSR_IA32_MCG_EXT_CTL] > > > > Signed-off-by: Haozhong Zhang > > [...] > > > > @@ -6433,6 +6455,8 @@ static __init int hardware_setup(void) > > > > > > > > kvm_set_posted_intr_wakeup_handler(wakeup_handler); > > > > > > > > + kvm_mce_cap_supported |= MCG_LMCE_P; > > > > > > Ah, so virtual LMCE is available on all processors! This is > > > interesting, but it also makes it more complicated to handle in QEMU; a > > > new QEMU generally doesn't require a new kernel. > > > > > > Eduardo, any ideas? > > > > (CCing libvirt list) > > > > As we shouldn't make machine-type changes introduce new host > > requirements, it looks like we need to either add a new set of > > CPU models (unreasonable), or expect management software to > > explicitly enable LMCE after ensuring the host supports it. > > > > Or we could wait for a reasonable time after the feature is > > available in the kernel, and declare that QEMU as a whole > > requires a newer kernel. But how much time would be reasonable > > for that? > > > > Long term, I believe we should think of a better solution. I > > don't think it is reasonable to require new libvirt code to be > > written for every single low-level feature that requires a newer > > kernel or newer host hardware. Maybe new introspection interfaces > > that would allow us to drop the "no new requirements on > > machine-type changes" rule? > > > > Because new MSR (MSR_IA32_MCG_EXT_CTL) and new MSR bit > (FEATURE_CONTROL_LMCE in MSR_IA32_FEATURE_CONTROL) are introduced by > LMCE, QEMU requires new KVM which can handle those changes. If I understood correctly, you are describing the second option above (declaring that QEMU as a whole requires a newer kernel). > > I'm not familiar with libvirt. Does the requirement of new KVM > capability bring any troubles to libvirt? It does, assuming that we still support running QEMU under an older kernel where KVM doesn't LMCE. In this case, the pc-2.6 machine-type will run, but the pc-2.7 machine-type won't. The requirement of new KVM capabilities based on the machine-type is a problem for livirt. libvirt have some host-capabilities APIs to allow software to check if the VM can be run on (or migrated to) a host, but none of them are based on machine-type. This is not necessarily specific to libvirt: people may have their own configuration or scripts that use the default "pc" alias, and a QEMU upgrade shouldn't break their configuration. -- Eduardo