Message ID | 20230420133724.11398-7-guang.zeng@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp381189vqo; Thu, 20 Apr 2023 07:32:18 -0700 (PDT) X-Google-Smtp-Source: AKy350Z8UYFWs8gT4QCSi8M09/+ahmNfiFICp2vNACSUg6s73pQBLvq8FNAxYVxTCB4MA5ZxRRBB X-Received: by 2002:a05:6a20:7283:b0:ef:daa2:4a40 with SMTP id o3-20020a056a20728300b000efdaa24a40mr2481334pzk.49.1682001137939; Thu, 20 Apr 2023 07:32:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682001137; cv=none; d=google.com; s=arc-20160816; b=QDqNTm/0rnt5QLAYfq9CXInq91V1VxsgA4Qvj2eE/BRt0msCr/X6o70Mnn0Mo1zLXf 8GYI2BjSJaMZqr6YdXNinW9//RUEHiHcbmNNEUiuU5RKl7IMTunZf6wf6WcxnZwe1isD U7DH25sGX6ePRhj8oFUT+nO7p7pn+Y1SucciK7J4k4t5bGRUkMXTWKlZWk/7U3qub5v1 IsjfzWz3NkZ/uaydQB/3+zXdK/w5aOQqQ5XBFhkXubL72Spxs7G9qdKMyaw1OIu3fWWh 4FEUeQP7uz+RUfszyCXTFWrJCiz4CG7yHB419FC0St8wJ7nyNl5LF/2Mntos4a0t/X0J K7VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=G8mdqNh1qUrnMIkJx+6cxUevKVNK3jbXU/6Z4d+ueWI=; b=iRsFhY0d71rFs8uLS0YCkDmQI4oiU9nqAIImOxQuRFk3VIugD8MBt3hCWPv3YNCNYM FBW0/3pGkBGKZWCOTkKofYXQTVFYskYlgU0gzJmsPIChgX4irbhImA5U2jYQc3Cnijb2 CXQy5XX5FtgEqj2mxk8HkE5SWHITgnQqVIj01ItipO1uFdLKlffsMEPsmudkYJ/5auUN fAfEw8QoKcA340+/LWRMXuqIV9539nPv1tTTzrprqGxv0n6hypL/NgobtFMsG39wN9Hk 30VWaPYEu2ejJjI1lkxEcIVCyoqTZekJoUeqHZTKpHIoVbVPk0oanzoHbUnrgl9C0ZXD fnUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=fQwdg0q9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u70-20020a638549000000b0050b51e62c19si1804876pgd.825.2023.04.20.07.32.02; Thu, 20 Apr 2023 07:32:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=fQwdg0q9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231951AbjDTOQo (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Thu, 20 Apr 2023 10:16:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231969AbjDTOQW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 20 Apr 2023 10:16:22 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A78C5FFB; Thu, 20 Apr 2023 07:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1682000181; x=1713536181; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=mBqjl0yhEeb8HytbOFw3rMDfti8h06Ban5qDOvLFqy8=; b=fQwdg0q9wJaME2h+ePIxss6z6WIOGNZOE+lkFBr7SdxMsNulLMQ5g+za EdaxQQDy6y5r5TgvdfEu+ilPQLvTy3frTK/keponnTSbMjylWgl/bOfA0 ijM0RO5EOtRQd/GJqeI92GVIaaVnbaU6pcHaR0Xgb1FTI2u/9fjzI1uXO XEoPrbcqZiz4nIjyDWB5kngCVo2aVw2RXdawkv7RmK9iUykiN6tsUxbR+ xaYvJdAEDOyHGPxLy4Tpf0Nd5WJvC7tTSOzeFm60J+6O4NM+uyxYKUaVl Z2zAXaOV4rNnnKjgE84G6LbRfZz5JPPgdZMSUCsEn2/ezi7udenIbY77k g==; X-IronPort-AV: E=McAfee;i="6600,9927,10686"; a="343217882" X-IronPort-AV: E=Sophos;i="5.99,212,1677571200"; d="scan'208";a="343217882" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2023 07:16:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10686"; a="816028928" X-IronPort-AV: E=Sophos;i="5.99,212,1677571200"; d="scan'208";a="816028928" Received: from arthur-vostro-3668.sh.intel.com ([10.238.200.53]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2023 07:16:16 -0700 From: Zeng Guang <guang.zeng@intel.com> To: Paolo Bonzini <pbonzini@redhat.com>, Sean Christopherson <seanjc@google.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, H Peter Anvin <hpa@zytor.com>, kvm@vger.kernel.org Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Gao Chao <chao.gao@intel.com>, Zeng Guang <guang.zeng@intel.com> Subject: [PATCH 6/6] KVM: x86: Set KVM LASS based on hardware capability Date: Thu, 20 Apr 2023 21:37:24 +0800 Message-Id: <20230420133724.11398-7-guang.zeng@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230420133724.11398-1-guang.zeng@intel.com> References: <20230420133724.11398-1-guang.zeng@intel.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763706025408085290?= X-GMAIL-MSGID: =?utf-8?q?1763706025408085290?= |
Series |
LASS KVM virtualization support
|
|
Commit Message
Zeng Guang
April 20, 2023, 1:37 p.m. UTC
Host kernel may clear LASS capability in boot_cpu_data.x86_capability
besides explicitly using clearcpuid parameter. That will cause guest
not being able to manage LASS independently. So set KVM LASS directly
based on hardware capability to eliminate the dependency.
Add new helper functions to facilitate getting result of CPUID sub-leaf.
Signed-off-by: Zeng Guang <guang.zeng@intel.com>
---
arch/x86/include/asm/cpuid.h | 36 ++++++++++++++++++++++++++++++++++++
arch/x86/kvm/cpuid.c | 4 ++++
2 files changed, 40 insertions(+)
Comments
On 4/20/2023 9:37 PM, Zeng Guang wrote: > Host kernel may clear LASS capability in boot_cpu_data.x86_capability Is there some option to do it? > besides explicitly using clearcpuid parameter. That will cause guest > not being able to manage LASS independently. So set KVM LASS directly > based on hardware capability to eliminate the dependency. > > Add new helper functions to facilitate getting result of CPUID sub-leaf. > > Signed-off-by: Zeng Guang <guang.zeng@intel.com> > --- > arch/x86/include/asm/cpuid.h | 36 ++++++++++++++++++++++++++++++++++++ > arch/x86/kvm/cpuid.c | 4 ++++ > 2 files changed, 40 insertions(+) > > diff --git a/arch/x86/include/asm/cpuid.h b/arch/x86/include/asm/cpuid.h > index 9bee3e7bf973..a25dd00b7c0a 100644 > --- a/arch/x86/include/asm/cpuid.h > +++ b/arch/x86/include/asm/cpuid.h > @@ -127,6 +127,42 @@ static inline unsigned int cpuid_edx(unsigned int op) > return edx; > } > > +static inline unsigned int cpuid_count_eax(unsigned int op, int count) > +{ > + unsigned int eax, ebx, ecx, edx; > + > + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); > + > + return eax; > +} > + > +static inline unsigned int cpuid_count_ebx(unsigned int op, int count) > +{ > + unsigned int eax, ebx, ecx, edx; > + > + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); > + > + return ebx; > +} > + > +static inline unsigned int cpuid_count_ecx(unsigned int op, int count) > +{ > + unsigned int eax, ebx, ecx, edx; > + > + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); > + > + return ecx; > +} > + > +static inline unsigned int cpuid_count_edx(unsigned int op, int count) > +{ > + unsigned int eax, ebx, ecx, edx; > + > + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); > + > + return edx; > +} > + > static __always_inline bool cpuid_function_is_indexed(u32 function) > { > switch (function) { > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 5facb8037140..e99b99ebe1fe 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -667,6 +667,10 @@ void kvm_set_cpu_caps(void) > F(AMX_FP16) | F(AVX_IFMA) > ); > > + /* Set LASS based on hardware capability */ > + if (cpuid_count_eax(7, 1) & F(LASS)) > + kvm_cpu_cap_set(X86_FEATURE_LASS); > + > kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX, > F(AVX_VNNI_INT8) | F(AVX_NE_CONVERT) | F(PREFETCHITI) > );
On 4/25/2023 10:57 AM, Binbin Wu wrote: > > On 4/20/2023 9:37 PM, Zeng Guang wrote: >> Host kernel may clear LASS capability in boot_cpu_data.x86_capability > Is there some option to do it? Kernel supporting LASS will turn off the LASS capability with specific option, e.g. "vsyscall=emulate". >> besides explicitly using clearcpuid parameter. That will cause guest >> not being able to manage LASS independently. So set KVM LASS directly >> based on hardware capability to eliminate the dependency. >> >> Add new helper functions to facilitate getting result of CPUID sub-leaf. >> >> Signed-off-by: Zeng Guang <guang.zeng@intel.com> >> --- >> arch/x86/include/asm/cpuid.h | 36 ++++++++++++++++++++++++++++++++++++ >> arch/x86/kvm/cpuid.c | 4 ++++ >> 2 files changed, 40 insertions(+) >> >> diff --git a/arch/x86/include/asm/cpuid.h b/arch/x86/include/asm/cpuid.h >> index 9bee3e7bf973..a25dd00b7c0a 100644 >> --- a/arch/x86/include/asm/cpuid.h >> +++ b/arch/x86/include/asm/cpuid.h >> @@ -127,6 +127,42 @@ static inline unsigned int cpuid_edx(unsigned int op) >> return edx; >> } >> >> +static inline unsigned int cpuid_count_eax(unsigned int op, int count) >> +{ >> + unsigned int eax, ebx, ecx, edx; >> + >> + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); >> + >> + return eax; >> +} >> + >> +static inline unsigned int cpuid_count_ebx(unsigned int op, int count) >> +{ >> + unsigned int eax, ebx, ecx, edx; >> + >> + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); >> + >> + return ebx; >> +} >> + >> +static inline unsigned int cpuid_count_ecx(unsigned int op, int count) >> +{ >> + unsigned int eax, ebx, ecx, edx; >> + >> + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); >> + >> + return ecx; >> +} >> + >> +static inline unsigned int cpuid_count_edx(unsigned int op, int count) >> +{ >> + unsigned int eax, ebx, ecx, edx; >> + >> + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); >> + >> + return edx; >> +} >> + >> static __always_inline bool cpuid_function_is_indexed(u32 function) >> { >> switch (function) { >> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c >> index 5facb8037140..e99b99ebe1fe 100644 >> --- a/arch/x86/kvm/cpuid.c >> +++ b/arch/x86/kvm/cpuid.c >> @@ -667,6 +667,10 @@ void kvm_set_cpu_caps(void) >> F(AMX_FP16) | F(AVX_IFMA) >> ); >> >> + /* Set LASS based on hardware capability */ >> + if (cpuid_count_eax(7, 1) & F(LASS)) >> + kvm_cpu_cap_set(X86_FEATURE_LASS); >> + >> kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX, >> F(AVX_VNNI_INT8) | F(AVX_NE_CONVERT) | F(PREFETCHITI) >> );
On Thu, Apr 20, 2023 at 09:37:24PM +0800, Zeng Guang wrote: >Host kernel may clear LASS capability in boot_cpu_data.x86_capability >besides explicitly using clearcpuid parameter. That will cause guest >not being able to manage LASS independently. So set KVM LASS directly >based on hardware capability to eliminate the dependency. ... >+ /* Set LASS based on hardware capability */ >+ if (cpuid_count_eax(7, 1) & F(LASS)) >+ kvm_cpu_cap_set(X86_FEATURE_LASS); >+ What if LASS is cleared in boot_cpu_data because not all CPUs support LASS? In arch/x86/kernel/cpu/common.c, identify_cpu() clears features which are not supported by all CPUs: /* * On SMP, boot_cpu_data holds the common feature set between * all CPUs; so make sure that we indicate which features are * common between the CPUs. The first time this routine gets * executed, c == &boot_cpu_data. */ if (c != &boot_cpu_data) { /* AND the already accumulated flags with these */ for (i = 0; i < NCAPINTS; i++) boot_cpu_data.x86_capability[i] &= c->x86_capability[i]; LA57 seems to have the same issue. We may need to add some checks for LA57 in KVM's cpu hotplug callback. > kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX, > F(AVX_VNNI_INT8) | F(AVX_NE_CONVERT) | F(PREFETCHITI) > ); >-- >2.27.0 >
diff --git a/arch/x86/include/asm/cpuid.h b/arch/x86/include/asm/cpuid.h index 9bee3e7bf973..a25dd00b7c0a 100644 --- a/arch/x86/include/asm/cpuid.h +++ b/arch/x86/include/asm/cpuid.h @@ -127,6 +127,42 @@ static inline unsigned int cpuid_edx(unsigned int op) return edx; } +static inline unsigned int cpuid_count_eax(unsigned int op, int count) +{ + unsigned int eax, ebx, ecx, edx; + + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); + + return eax; +} + +static inline unsigned int cpuid_count_ebx(unsigned int op, int count) +{ + unsigned int eax, ebx, ecx, edx; + + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); + + return ebx; +} + +static inline unsigned int cpuid_count_ecx(unsigned int op, int count) +{ + unsigned int eax, ebx, ecx, edx; + + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); + + return ecx; +} + +static inline unsigned int cpuid_count_edx(unsigned int op, int count) +{ + unsigned int eax, ebx, ecx, edx; + + cpuid_count(op, count, &eax, &ebx, &ecx, &edx); + + return edx; +} + static __always_inline bool cpuid_function_is_indexed(u32 function) { switch (function) { diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 5facb8037140..e99b99ebe1fe 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -667,6 +667,10 @@ void kvm_set_cpu_caps(void) F(AMX_FP16) | F(AVX_IFMA) ); + /* Set LASS based on hardware capability */ + if (cpuid_count_eax(7, 1) & F(LASS)) + kvm_cpu_cap_set(X86_FEATURE_LASS); + kvm_cpu_cap_init_kvm_defined(CPUID_7_1_EDX, F(AVX_VNNI_INT8) | F(AVX_NE_CONVERT) | F(PREFETCHITI) );