From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754495AbcFPO4E (ORCPT ); Thu, 16 Jun 2016 10:56:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45336 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754239AbcFPOzy (ORCPT ); Thu, 16 Jun 2016 10:55:54 -0400 Date: Thu, 16 Jun 2016 11:55:46 -0300 From: Eduardo Habkost To: Paolo Bonzini Cc: Haozhong Zhang , 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: <20160616145546.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1785f481-033b-2780-37b8-d27f80276d33@redhat.com> 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.25]); Thu, 16 Jun 2016 14:55:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? -- Eduardo