Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757903AbcJaKSt (ORCPT ); Mon, 31 Oct 2016 06:18:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:12198 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754122AbcJaKSo (ORCPT ); Mon, 31 Oct 2016 06:18:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,426,1473145200"; d="scan'208";a="1052884931" From: "Luc, Piotr" To: "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" , "pbonzini@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/lFjbKC9k48AgAACjwCAAA5mAIAAEG2AgAAD64CAAZJOgIADACOAgAAL6gCAAAWugA== Date: Mon, 31 Oct 2016 10:18:41 +0000 Message-ID: <1477908811.32008.20.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> <1477905033.32008.5.camel@intel.com> <20161031095312.dzv3rj2fqgjjsy7w@pd.tnic> In-Reply-To: <20161031095312.dzv3rj2fqgjjsy7w@pd.tnic> 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: <6092855ECD94C24CA5FD9B50672A770F@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 u9VAIsx4028050 Content-Length: 1026 Lines: 24 On Mon, 2016-10-31 at 10:53 +0100, Borislav Petkov wrote: > > 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.  > > Errr, I can't parse that reading it backwards and forwards. Please > elaborate. The patch that introduces AVX512_4VNNIW and AVX512_4FMAPS features was merged to kernel 4.9-rc2 so we have possibility to mask the feature bits using 'noxsave' option in kernel cmdline. This option clears all AVX512 feature bits in boot_cpu_data.x86_capability. The cpuid_mask function, which usually used in kvm, read bit from this x86_capabity and mask out. This prevents passing disabled features to guest. If we use cpu_count instead, which reports bits directly from CPU, then the bits of features that are disabled in host are passed to guest as enabled. This seems be inconsistent. Thanks, Piotr