[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/ucode: Refresh raw CPU policy after microcode load
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 4 May 2023 09:08:00 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EMCovZM5a+5Fe3ZHk/ZrcwEFDoMx44Y0U1aq3mDeCHg=; b=X8sKn/gVa9kMTKvq1sS3RKaynzLi5t7cYOB9lwc6hoQs7Bj1IxxPSj3Q5SjhzCEu3IwECN0mAaX84s91pnxD0k4hjITOwYMDCHfHZCjs5fQyVJaHeABfu4SHJlRi4wLnUpCEUOoyWecepMQCzeXDYmYznikVhw6ollNuhHVqdyUwPufBAYRvmiAFvL5rHinOglAHh4RN7aASnUSeBVySsSX+8HTdkIj6OPMiu+MSxkJqPgP75k9GoDO+O4978NTL2D6txcHRUNjVTH5VX2GZSYkmYqmH0+c8bOO9pN1o/rz29kvJcmasDR73m5iKVQTU9h8/Y0GgGJ6AcLDlAuBikw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SJK8lApNMuCDa6EhPpym/yWjsLTlG0QQxtoUFI8cYht1bOXkHwW7dhvGMlwcNg1uKmCJ9WZsSJlqcj/fXU3NNIc+rK4dNn2OCAQ6SKn3OHAujEbQwntMc3lsDY2+0HSQp7Fhqyh+M2IfyGmC552qx7idEL8sor5IaHxX3ihbG7Al5f7sEQovpjBlCOYARHZZLclK7iRWDxb/nn6d4yVd6edvLsDoIsO+qkDuBzTcKQkH9NedTj7dmW37mDkt8KcPayhtc2uWn40db1qp9pua2HXtphd3QZ69wM09sA7RZb79VHP+vmvQhXw1pBIJ9NdiIeKMHDgJWVPJPdtxj3oKlw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 04 May 2023 07:08:28 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 03.05.2023 20:58, Andrew Cooper wrote:
> Loading microcode can cause new features to appear.
Or disappear (LWP)? While I don't think we want to panic() in this
case (we do on the S3 resume path when recheck_cpu_features() fails
on the BSP), it would seem to me that we want to go a step further
than you do and at least warn when a feature went amiss. Or is that
too much of a scope-creeping request right here?
> @@ -677,6 +678,9 @@ static long cf_check microcode_update_helper(void *data)
> spin_lock(µcode_mutex);
> microcode_update_cache(patch);
> spin_unlock(µcode_mutex);
> +
> + /* Refresh the raw CPU policy, in case the features have changed. */
> + calculate_raw_cpu_policy();
I understand this is in line with what we do during boot, but there
and here I wonder whether this wouldn't better deal with possible
asymmetries (e.g. in case ucode loading failed on one of the CPUs),
along the lines of what we do near the end of identify_cpu() for
APs. (Unlike the question higher up, this is definitely only a
remark here, not something I'd consider dealing with right in this
change.)
Jan
|
