Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763688AbcJaJPt (ORCPT ); Mon, 31 Oct 2016 05:15:49 -0400 Received: from mga06.intel.com ([134.134.136.31]:48751 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753560AbcJaJPr (ORCPT ); Mon, 31 Oct 2016 05:15:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,426,1473145200"; d="scan'208";a="185809472" From: "Luc, Piotr" To: "pbonzini@redhat.com" , "bp@alien8.de" CC: "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "he.chen@linux.intel.com" , "tglx@linutronix.de" , "x86@kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "Kang, Luwei" , "rkrcmar@redhat.com" Subject: Re: [PATCH] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest Thread-Topic: [PATCH] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest Thread-Index: AQHSMPuRndHUs4kUQU6QbMeh/lFjbKC9k48AgAACjwCAAA5mAIAAEG2AgAAD64CAAZJOgIADACOA Date: Mon, 31 Oct 2016 09:15:43 +0000 Message-ID: <1477905033.32008.5.camel@intel.com> References: <1477645960-6898-1-git-send-email-he.chen@linux.intel.com> <1477649272.17668.7.camel@intel.com> <5c00fdf0-a5a4-7a78-4ed8-8ae3ef710a68@redhat.com> <20161028110834.svzzs5hftg3bybiz@pd.tnic> <20161028122123.24i3synevehn6r3p@pd.tnic> <425702906.9319122.1477743677017.JavaMail.zimbra@redhat.com> In-Reply-To: <425702906.9319122.1477743677017.JavaMail.zimbra@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.237.138.164] Content-Type: text/plain; charset="utf-8" Content-ID: <5742FD08AFDFAA40856FE869ADDF1633@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u9V9GA3E027763 Content-Length: 594 Lines: 17 On Sat, 2016-10-29 at 08:21 -0400, Paolo Bonzini wrote: > > Currently none of the bits in CPUID[7,0].edx is ever masked by the > host, so > this would be enough.  If we ever need to do some masking, I guess > I'll > practice my puss-in-boots look and submit a patch to add CPUID[7,0] > back > as a separate cpufeature entr. I think that in v4.9-rc2 the CPUID[7,0].edx bits can be masked out by applying noxsave to cmdline. Using directly cpu_count will result in passing the bits in edx to a guest directly while the xsaveopt and rest of AVX512 features bits will be cleared.  Thx Piotr