Message ID | 20231108183003.5981-12-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp1125691vqo; Wed, 8 Nov 2023 11:04:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IFO+kOiA5cG98L2pCLahnA/iBZn9reMnSR2ow95y/7uLlWaGY0Owt7oIHungkoV7HmisMPK X-Received: by 2002:a05:6870:4f83:b0:1e9:b550:c05a with SMTP id xj3-20020a0568704f8300b001e9b550c05amr4032938oab.53.1699470293517; Wed, 08 Nov 2023 11:04:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699470293; cv=none; d=google.com; s=arc-20160816; b=knqMBwZJsIo7tdOV444hQcvVz/lhWoHU9Z+7UOp3t8AII2QQ8+ocFNTU7ti+PP89X7 kfqn79TMpxfb/Ajt02O/k2ddNkoubWeMywd0xNcbZ4rKO0yR7QfV5TFQ411Q2mEbvowF ImhYheL8YC/4s/O+3hEMN5ORlNTwzFxxJ3J9bZazzalkTsoIqhwN9x215XDI1RFrGiH4 /ELrre6++IgSra1bKUs6PsDtq0JZ9dTuN4ZHfQmr0yVW1KKhVQdlGkiCk0sbazlWcfqo yiAL4ESFlq2w1mQtKm6fEsveZSs+9P59qz7oVaCTzn807SuaiumE4luhQeBVfUJCq53D w2EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=q+uuzg/GgTMz8qw2z7LwVlE9oxIyB9+MppZMvG2Pq5Y=; fh=jyCs2STAghiemYCMqutk2CMon3BCEX6sSSqaVLqDaaU=; b=B/iPLtxzPu2LGKFQ3rpYSmhZcDQJyrrKYjhgX9eoy5uLDUGEf4OC+MTg7n8DrmUnXV KS+ILULZEK5Ppn+5TettW6M7rD9dbsMe8F+gJF6jQCJMDdTcz0wSC32U3osfWdIbFmUd Py0rBP/HFPlL6SQ16asUPw9O4QwirDX2xN7Q4EJVZmFKQcV909qeHpWDGxBtOsE6Uurv ACJQs0ocw4lUv5XoZGzagaVCg4+jiMAUl66WaSNFdR0uVWqnS25gH0zzvBTXiwlbScQC rWkJPdavqy/6Jn5rr1LF8eGYo8VjgpE2e45w8JZZAX1IMN4cHZkPrdUX9MPXtwK0mBDB U37A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=aLw8KsUc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 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 snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id a26-20020a056830009a00b006c34ee565c3si5513410oto.159.2023.11.08.11.04.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Nov 2023 11:04:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=aLw8KsUc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id DC54F822CDCA; Wed, 8 Nov 2023 11:01:42 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232730AbjKHTBB (ORCPT <rfc822;jaysivo@gmail.com> + 32 others); Wed, 8 Nov 2023 14:01:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232575AbjKHTAY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Nov 2023 14:00:24 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C12B211B; Wed, 8 Nov 2023 11:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699470023; x=1731006023; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jUWUSU0yemX10hpGHyFVYNgeNUAOt//vvysT2zi1z38=; b=aLw8KsUcHEfiXXdG2SO22WOmbKy5+P20UUlX9Z5nVMl2ffgeC2mshU6H jJBV9DRBiKVCnp6icqg4fDgukZMujxL8sFmP44bkEUCbtBLBFSO1eWjNV 3UYJMHCoLog3VJ28+iWFxpDlK/ZlEUwknzTBxW0eO6WrFBdWqs7sBMXWE qmgAUCgzqqQt8Np0+c71E8fuVRu5GlTyOUQnfLtQhV5lcm9wgFyi67+mG RKRIQyd6hVH8Om8H2vnBdexUNpHLghCz+bltMw5LgjB4nl/K1WElAkUhn piwX/3jPTMIHNB4z9hRMXIv5owT4p2a4DL6EXTklMGncRqliG5LUF7Dzw Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10888"; a="8486337" X-IronPort-AV: E=Sophos;i="6.03,287,1694761200"; d="scan'208";a="8486337" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2023 11:00:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.03,287,1694761200"; d="scan'208";a="10892466" Received: from unknown (HELO fred..) ([172.25.112.68]) by orviesa001.jf.intel.com with ESMTP; 08 Nov 2023 11:00:21 -0800 From: Xin Li <xin3.li@intel.com> To: kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kselftest@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, corbet@lwn.net, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, vkuznets@redhat.com, peterz@infradead.org, ravi.v.shankar@intel.com Subject: [PATCH v1 11/23] KVM: x86: Add kvm_is_fred_enabled() Date: Wed, 8 Nov 2023 10:29:51 -0800 Message-ID: <20231108183003.5981-12-xin3.li@intel.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231108183003.5981-1-xin3.li@intel.com> References: <20231108183003.5981-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 08 Nov 2023 11:01:43 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782023761958644459 X-GMAIL-MSGID: 1782023761958644459 |
Series |
Enable FRED with KVM VMX
|
|
Commit Message
Li, Xin3
Nov. 8, 2023, 6:29 p.m. UTC
Add kvm_is_fred_enabled() to get if FRED is enabled on a vCPU. Tested-by: Shan Kang <shan.kang@intel.com> Signed-off-by: Xin Li <xin3.li@intel.com> --- arch/x86/kvm/kvm_cache_regs.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
Comments
On Wed, Nov 08, 2023 at 10:29:51AM -0800, Xin Li wrote: >Add kvm_is_fred_enabled() to get if FRED is enabled on a vCPU. > >Tested-by: Shan Kang <shan.kang@intel.com> >Signed-off-by: Xin Li <xin3.li@intel.com> >--- > arch/x86/kvm/kvm_cache_regs.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > >diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h >index 75eae9c4998a..390643e8c532 100644 >--- a/arch/x86/kvm/kvm_cache_regs.h >+++ b/arch/x86/kvm/kvm_cache_regs.h >@@ -187,6 +187,16 @@ static __always_inline bool kvm_is_cr4_bit_set(struct kvm_vcpu *vcpu, > return !!kvm_read_cr4_bits(vcpu, cr4_bit); > } > >+static __always_inline bool kvm_is_fred_enabled(struct kvm_vcpu *vcpu) >+{ >+#ifdef CONFIG_X86_64 >+ return cpu_feature_enabled(X86_FEATURE_FRED) && >+ kvm_is_cr4_bit_set(vcpu, X86_CR4_FRED); FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the check about long mode? >+#else >+ return false; >+#endif >+} >+ > static inline ulong kvm_read_cr3(struct kvm_vcpu *vcpu) > { > if (!kvm_register_is_available(vcpu, VCPU_EXREG_CR3)) >-- >2.42.0 > >
> >+ return cpu_feature_enabled(X86_FEATURE_FRED) && > >+ kvm_is_cr4_bit_set(vcpu, X86_CR4_FRED); > > FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the > check about long mode? It won' t allow CR4.FRED to be set if not in long mode, I don't expect it at runtime. Or you have one? If you are talking about save/restore a corrupted vCPU state, a following VM entry should fail anyway.
On Tue, Nov 14, 2023 at 12:42:13PM +0800, Li, Xin3 wrote: >> >+ return cpu_feature_enabled(X86_FEATURE_FRED) && >> >+ kvm_is_cr4_bit_set(vcpu, X86_CR4_FRED); >> >> FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the >> check about long mode? > >It won' t allow CR4.FRED to be set if not in long mode, I don't expect it >at runtime. Or you have one? I was thinking about a very contrived case: 1. the CPU enters 64-bit long mode and sets CR4.FRED 2. the CPU switches out of 64-bit long mode and SDM vol3 chapter 2.5 CONTROL REGISTERS says: A 64-bit capable processor will retain the upper 32 bits of each control register when transitioning out of IA-32e mode. so, to me, it is possible that CR4.FRED is 1 while IA32_EFER.LMA is 0. and in this case, FRED should be considered disabled. Anyway, I think we should align with FRED SPEC. If we deliberately omit the check about long mode, please add a comment to explain why it is ok to do that. > >If you are talking about save/restore a corrupted vCPU state, a following >VM entry should fail anyway.
> >> FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the > >> check about long mode? > > > >It won' t allow CR4.FRED to be set if not in long mode, I don't expect it > >at runtime. Or you have one? > > I was thinking about a very contrived case: > > 1. the CPU enters 64-bit long mode and sets CR4.FRED > 2. the CPU switches out of 64-bit long mode > > and SDM vol3 chapter 2.5 CONTROL REGISTERS says: > > A 64-bit capable processor will retain the upper 32 bits of each control > register when transitioning out of IA-32e mode. > > so, to me, it is possible that CR4.FRED is 1 while IA32_EFER.LMA is 0. > and in this case, FRED should be considered disabled. You're correct, this is a solid case. It's not one-way, but I forgot the other way around. > > Anyway, I think we should align with FRED SPEC. If we deliberately omit > the check about long mode, please add a comment to explain why it is ok > to do that. Yeah, I will add it.
> > >> FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to > > >> omit the check about long mode? > > > > > >It won' t allow CR4.FRED to be set if not in long mode, I don't > > >expect it at runtime. Or you have one? > > > > I was thinking about a very contrived case: > > > > 1. the CPU enters 64-bit long mode and sets CR4.FRED 2. the CPU > > switches out of 64-bit long mode Actually, SDM3 Section 10.8.5 Initializing IA-32e Mode says: 64-bit mode consistency checks fail on attempts to enable or disable IA-32e mode while paging is enabled. In another word, the CPU allows software to modify IA32_EFER.LME only when CR0.PG = 0 (i.e., only in legacy mode). Thus, attempts to do so when CR0.PG = 1 will cause #GP. Remember FRED only works with 64-bit kernel, which can be entered only if paging is enabled. As such, to clear IA32_EFER.LME, OS/VMM needs to turn off paging first. And to turn off paging, 64-bit mode needs to be turned off (to enter compatibility mode in ring 0 because it's not allowed to disable paging in 64-bit mode). Thus CR4.FRED needs be cleared first. So CR4.FRED fully indicates whether FRED is enabled or not, which is why FRED spec 5.0 section 9.5 says so. But we can put more explanation there.
diff --git a/arch/x86/kvm/kvm_cache_regs.h b/arch/x86/kvm/kvm_cache_regs.h index 75eae9c4998a..390643e8c532 100644 --- a/arch/x86/kvm/kvm_cache_regs.h +++ b/arch/x86/kvm/kvm_cache_regs.h @@ -187,6 +187,16 @@ static __always_inline bool kvm_is_cr4_bit_set(struct kvm_vcpu *vcpu, return !!kvm_read_cr4_bits(vcpu, cr4_bit); } +static __always_inline bool kvm_is_fred_enabled(struct kvm_vcpu *vcpu) +{ +#ifdef CONFIG_X86_64 + return cpu_feature_enabled(X86_FEATURE_FRED) && + kvm_is_cr4_bit_set(vcpu, X86_CR4_FRED); +#else + return false; +#endif +} + static inline ulong kvm_read_cr3(struct kvm_vcpu *vcpu) { if (!kvm_register_is_available(vcpu, VCPU_EXREG_CR3))