[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1477649272.17668.7.camel@intel.com>
Date: Fri, 28 Oct 2016 10:13:01 +0000
From: "Luc, Piotr" <Piotr.Luc@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"he.chen@...ux.intel.com" <he.chen@...ux.intel.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"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 Fri, 2016-10-28 at 17:12 +0800, He Chen wrote:
> The spec can be found in Intel Software Developer Manual or in
> Instruction Set Extensions Programming Reference.
>
> Signed-off-by: Luwei Kang <luwei.kang@...el.com>
> Signed-off-by: He Chen <he.chen@...ux.intel.com>
> ---
> arch/x86/kvm/cpuid.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index afa7bbb..328b169 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -376,6 +376,10 @@ static inline int __do_cpuid_ent(struct
> kvm_cpuid_entry2 *entry, u32 function,
> /* cpuid 7.0.ecx*/
> const u32 kvm_cpuid_7_0_ecx_x86_features = F(PKU) | 0
> /*OSPKE*/;
>
> + /* cpuid 7.0.edx*/
> + const u32 kvm_cpuid_7_0_edx_x86_features =
> + 0x4 /* AVX512-4VNNIW */ | 0x8 /* AVX512-4FMAPS */;
> +
> /* all calls to cpuid_count() should be made on the same cpu
> */
> get_cpu();
>
> @@ -458,12 +462,13 @@ static inline int __do_cpuid_ent(struct
> kvm_cpuid_entry2 *entry, u32 function,
> /* PKU is not yet implemented for shadow
> paging. */
> if (!tdp_enabled)
> entry->ecx &= ~F(PKU);
> + entry->edx &= kvm_cpuid_7_0_edx_x86_features;
The cpu_mask() is missed here.
I understand that it doesn't work for this scattered features but the
bits in edx must be zeroed if corresponding flags were cleared in
fpu__xstate_clear_all_cpu_caps.
So this implies more work unfortunately.
> } else {
> entry->ebx = 0;
> entry->ecx = 0;
> + entry->edx = 0;
> }
> entry->eax = 0;
> - entry->edx = 0;
> break;
> }
> case 9:
Powered by blists - more mailing lists