[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48ef617f-c438-cfcf-6f0c-1eb3b59820ff@redhat.com>
Date: Mon, 31 Oct 2016 11:47:48 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Borislav Petkov <bp@...en8.de>, "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>,
"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 31/10/2016 11:30, Borislav Petkov wrote:
> 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.
Yes, indeed. :(
The information is all in arch/x86/kernel/cpu/scattered.c's cpuid_bits
array. Borislav, would it be okay to export the cpuid_regs enum?
Paolo
Powered by blists - more mailing lists