Received-SPF: pass (google.com: domain of linux-kernel+bounces-169561-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <e39f609f-314b-43c7-b297-5c01e90c023a@intel.com>
Date: Mon, 6 May 2024 17:19:18 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace
To: Sean Christopherson <seanjc@google.com>
CC: <pbonzini@redhat.com>, <dave.hansen@intel.com>, <x86@kernel.org>,
	<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<peterz@infradead.org>, <chao.gao@intel.com>, <rick.p.edgecombe@intel.com>,
	<mlevitsk@redhat.com>, <john.allen@amd.com>
References: <20240219074733.122080-1-weijiang.yang@intel.com>
 <20240219074733.122080-25-weijiang.yang@intel.com>
 <ZjLNEPwXwPFJ5HJ3@google.com>
Content-Language: en-US
From: "Yang, Weijiang" <weijiang.yang@intel.com>
In-Reply-To: <ZjLNEPwXwPFJ5HJ3@google.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cjZXWFViekMvY1ZvSkZyNldFQ1RiMEt5azZRYTdmNjZPWFMzbHQweDJJZEo1?=
 =?utf-8?B?aWlaY1IwQkdKUDBZby9pck14ZXRBSUd1Y1Y2ZkdvYk83NmlrUm92SVN0OG54?=
 =?utf-8?B?NjVlQ2dqS2wyckdMTUFYOUpyNFlvMXlvWnltbEhGZ0lsVk1YZk9lU1Z1am9z?=
 =?utf-8?B?SitRTnNMd2NkQWNhd3puc1pWQjNqWG9zYjFESjQyeHJYcXA2TjhQajd1eUZ5?=
 =?utf-8?B?ZE1GRkVHdmNqUVhtYXhxbHMxUEU3KzhQbFFtdms2ckZpTGtlbitybG42Kytq?=
 =?utf-8?B?N1N1UlF5cUNqbzNBUjJmQXpGSW5ndlZyOVFtMVNYR29mbldOenpSTy9mU1U4?=
 =?utf-8?B?S2RpUDNsRXd6MWpmNWNMejFQaWpLa3NmMzU3clJscFBRWjRoWlcybGNGSXhn?=
 =?utf-8?B?dEpIaFY4UXh5VUQ1NUI0WU8weHFQNE9rRmQ4ZndxQ2tsaVEwYk5kTUdFdm9u?=
 =?utf-8?B?d2VESUVIdjJiNEgreUQ3NXJHU2M0VDh2MmVNdm9wbDRQb05paDhoZFdGQnJW?=
 =?utf-8?B?Z2FOOW9lTGNOOGZ0SWlLWmFoMEgxL0lGOVJWTUxDb1NWMGphblIxMHErR0lF?=
 =?utf-8?B?Q09TM3F2QjFwMGp5U0VBNkRubkJ4ZWJmT3ZkbW5NNklNeUlLTGhkKytFS084?=
 =?utf-8?B?R1dZeXNSL3RIckZzdEVXaDhIL2RhNi9OZjlCVFdGeVFDZnFXWDdnOGlsbGZk?=
 =?utf-8?B?OSs3RGV4VjBHUnZxNjBrYldOeGhENTlrVGxvN2dzSFl2UlUzY3dTK1ZORHA2?=
 =?utf-8?B?cFJ2K2c5Zkh1K0pGTGxmcm8wUkh6WDlsM2k3S2p0RFVRNEx6RjRJSExITENa?=
 =?utf-8?B?NVlmb1BmdWZSK1EzSzNsWFVJakFGTmlHZzh3V2lQVXRSVC9nbXNZRE90Tzds?=
 =?utf-8?B?Mi82Um9LalBzbnpjVDVKTUM0QW1JUFRrZ0h1cTFwekNBUXdHTHNibXl6SmUx?=
 =?utf-8?B?UzdRc1UzT09QV2NtMDNlT1N4VmpqUlVlUFVHR3p5eTY3TUdnUzVUZ3g0Z3pS?=
 =?utf-8?B?VlltMEZQdUVPc2V0TUsyZ3daME1MT290bDZzQlFGZXNOemxMWGl0dEYxY3Jj?=
 =?utf-8?B?UXlwQ1poQWJ2dkdsaENXMC9CS2h1QnVsTzA4NzdmZ0t0aHN3bDB6SHVjNHg3?=
 =?utf-8?B?ZC9aYVhoZHdVWk4zM09vNEowcDZXQ0ZkcVg3Y0dINTd3dzlFMmR0KzhScEdK?=
 =?utf-8?B?ZGZCV2lSMFZuM3BZTEU1bmdPd0FDRDNYNmRRdEltdWg5V3FCM2hqSXg2WDNk?=
 =?utf-8?B?aVNHY1RMRTh4YXRocEJpVkdneU4yU1BhbUs3Q0NQWUdUWXRQbnBlTjZkTGph?=
 =?utf-8?B?Q04wL0x2U2RJdWYvUFk5S3NmRDVOZXp3ZGxjQTRjVldYUHB2ajFaWEg1TWln?=
 =?utf-8?B?VFJ1SmcvcVNsMUhUa0NMYXp4TWpCN3ZhNnl1ZFRVcXJxRXE4ZzAyeVpoYXFP?=
 =?utf-8?B?UXJCYUlRRVJibHprY2t0b21LZ0ZIa2lTUFNDd2ZrZ3VVTVJKV01PVnBXQld2?=
 =?utf-8?B?dzh4aVFncjJhLzZxcGhPTFRTUmt0OS81WVpvcXkyOXNTRUdybEN2T2lBSXVM?=
 =?utf-8?B?T3RMQlpKWmhjaXRscjZWNk9KZUx1bitQMzQwSGZTNUhQb1Y3YmhiSnhwYy9v?=
 =?utf-8?B?QWFxcDEzcWdwa3FXY1B3eEl6RFRVNDM3eFlhMGkyUURNeW5rZk9ac2lpMkVF?=
 =?utf-8?B?aDdyVm5KeHUyYWZPQ3BuTGN1eVB6L1NuQXYxam5uU05QWWhqalFUWDZPdERo?=
 =?utf-8?B?ZVRaWUF2UDhHNVlIMCtsRFBVT2ljL2g5Ny9KdFg3MTlTVmdYb0wrZ2xrcWxV?=
 =?utf-8?B?NC9HU1JPUVZFYlBRNEZ5bFJjTHFJamxaMmxMdUxFWW5QZDV3R2NCd29CdGpn?=
 =?utf-8?B?L1hocUlCUGJBTk5Ia2lhMnJvZkdNQ1NsLzlIajMybCtjdmZ2UFA4citpdEJX?=
 =?utf-8?B?eTM1R2Nob0syQnVVb3Q1OGZLZUdpbHRtMDVMWjF5SEl2Y01SRlY5UGM0V2c4?=
 =?utf-8?B?cEdtOERzMWlnV05FdHp4WnpCY1d4R2t3VFc0UEVGelJoU3VkbzVsYWJTZEds?=
 =?utf-8?B?NFZOM2h6eEZtQnlSU1JOdFI1b29LKzkrbXI3R3VPKzZFSHpYSnpCMVdXYUpN?=
 =?utf-8?B?WjN5Y2xIVm5QM2UyUGV0R1IwVTVNcmErNW84L2hjQ1pWQzBDYUJWbmdjWVVa?=
 =?utf-8?B?M2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5bc99361-ec2f-439a-b078-08dc6dada10d
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4965.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2024 09:19:28.2164
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7m0UlwBWFO3+zi6SbTKoYt15yLbsgCPnqyI244gYsFWYikuerb3cIPz2u9lbHZOwoEC9qESRxRuxKlh4EWH5ig==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB7110
X-OriginatorOrg: intel.com

On 5/2/2024 7:15 AM, Sean Christopherson wrote:
> On Sun, Feb 18, 2024, Yang Weijiang wrote:
>> @@ -696,6 +697,20 @@ void kvm_set_cpu_caps(void)
>>   		kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP);
>>   	if (boot_cpu_has(X86_FEATURE_AMD_SSBD))
>>   		kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD);
>> +	/*
>> +	 * Don't use boot_cpu_has() to check availability of IBT because the
>> +	 * feature bit is cleared in boot_cpu_data when ibt=off is applied
>> +	 * in host cmdline.
> I'm not convinced this is a good reason to diverge from the host kernel.  E.g.
> PCID and many other features honor the host setup, I don't see what makes IBT
> special.

This is mostly based on our user experience and the hypothesis for cloud computing:
When we evolve host kernels, we constantly encounter issues when kernel IBT is on,
so we have to disable kernel IBT by adding ibt=off. But we need to test the CET features
in VM, if we just simply refer to host boot cpuid data, then IBT cannot be enabled in
VM which makes CET features incomplete in guest.

I guess in cloud computing, it could run into similar dilemma. In this case, the tenant
cannot benefit the feature just because of host SW problem. I know currently KVM
except LA57 always honors host feature configurations, but in CET case, there could be
divergence wrt honoring host configuration as long as there's no quirk for the feature.

But I think the issue is still open for discussion...

>
> LA57 is special because it's entirely reasonable, likely even, for a host to
> only want to use 48-bit virtual addresses, but still want to let the guest enable
> LA57.
>
>> @@ -4934,6 +4935,14 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
>>   
>>   	vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, 0);  /* 22.2.1 */
>>   
>> +	if (kvm_cpu_cap_has(X86_FEATURE_SHSTK)) {
>> +		vmcs_writel(GUEST_SSP, 0);
>> +		vmcs_writel(GUEST_S_CET, 0);
>> +		vmcs_writel(GUEST_INTR_SSP_TABLE, 0);
>> +	} else if (kvm_cpu_cap_has(X86_FEATURE_IBT)) {
>> +		vmcs_writel(GUEST_S_CET, 0);
>> +	}
> Similar to my comments about MSR interception, I think it would be better to
> explicitly handle the "common" field.  At first glance, code like the above makes
> it look like IBT is mutually exclusive with SHSTK, e.g. a reader that isn't
> looking closely could easily miss that both paths write GUEST_S_CET.

Sure,thanks!

>
> 	if (kvm_cpu_cap_has(X86_FEATURE_SHSTK)) {
> 		vmcs_writel(GUEST_SSP, 0);
> 		vmcs_writel(GUEST_INTR_SSP_TABLE, 0);
> 	}
> 	if (kvm_cpu_cap_has(X86_FEATURE_IBT) ||
> 	    kvm_cpu_cap_has(X86_FEATURE_SHSTK))
> 		vmcs_writel(GUEST_S_CET, 0);