[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161031103050.k7b2l64blhmv33mw@pd.tnic>
Date: Mon, 31 Oct 2016 11:30:50 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Luc, Piotr" <Piotr.Luc@...el.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"he.chen@...ux.intel.com" <he.chen@...ux.intel.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Kang, Luwei" <luwei.kang@...el.com>,
"rkrcmar@...hat.com" <rkrcmar@...hat.com>
Subject: Re: [PATCH] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS
features to kvm guest
On Mon, Oct 31, 2016 at 10:18:41AM +0000, Luc, Piotr wrote:
> 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
Ah, you mean cpuid_count().
> CPU, then the bits of features that are disabled in host are passed to
> guest as enabled. This seems be inconsistent.
Ok, I see what you mean.
So I guess we'll have to iterate over the cpuid_bits[] array and
recreate the CPUID leaf for KVM instead, as I suggested earlier.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists