[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 4/4] x86/microcode: Disable microcode update handler if DIS_MCU_UPDATE is set


  • To: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 5 Jul 2023 12:51:47 +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=8bvbw1tm6Hz3nLztoL7t76OJzMGSv4pIc1wPZMxG4Y0=; b=B9pnlgNzv09LK+tWRIBijygOU2x2aH9QSmF/S0sUGYws0mSuPaqR57NIcM6ifjbHeqbrEOvcVNY0m0v9e9lgPqWnonDl9b3ww7b+1TfvJryNJ6dJ1hZQw93ht38SOOSx+NJQU1hUSTwvT0PbjM6LsruTwAyvX1lLvC9bwZw3mnbSFSiZULYs8vq40U8pGNKrVpN9pQeCjanlALipGYj40CPRG7wNXkmkn0jOsfMqoAprVQL1jSC8uEJKFYv7wZ6u2fJ1lRCytkLFNkRIY4yG2SXu2OPzCpTzKRhaRVilkDMbDsKA57734dcMVILOEtdB2KMDkZcQG0OsiaD30WSX+Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VXPo1JLr+obMsXGZuEehwW9JiHVghp+Ge65CETrq15vzZq4zt9oqvzrnE7tkpAf9XFrMvHl5TDM16Gh7ASo/6pG7NyjyVa4/r4jiQKeAIXaypwzgBhSLrYAcjxIqJ/vq+FOXzLea66dXwITApFoffi6Hdqa938lCfk+pooCvLtZjzg0amJg/LLXWMyChQrIv8z88YpeYK/5u/L2ZwYBItM0+31SjVdl4MF07sCIJC/7+67V+7Vf4a0aVzKEwwDvpKtwLYbfCu0hlxWxpnrOaIYnNuP0TDaav4ddnI9PV56XkEHjD5Mxs0dKIK9OsXotAgKt50jtfMi8pB8WnI4I6Wg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 05 Jul 2023 10:52:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.06.2023 17:26, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -847,17 +847,21 @@ int __init early_microcode_init(unsigned long 
> *module_map,
>  {
>      const struct cpuinfo_x86 *c = &boot_cpu_data;
>      int rc = 0;
> +    bool can_load = false;
>  
>      switch ( c->x86_vendor )
>      {
>      case X86_VENDOR_AMD:
>          if ( c->x86 >= 0x10 )
> +        {
>              ucode_ops = amd_ucode_ops;
> +            can_load = true;
> +        }
>          break;
>  
>      case X86_VENDOR_INTEL:
> -        if ( c->x86 >= 6 )
> -            ucode_ops = intel_ucode_ops;
> +        ucode_ops = intel_ucode_ops;
> +        can_load = intel_can_load_microcode();
>          break;
>      }
>  
> @@ -874,7 +878,7 @@ int __init early_microcode_init(unsigned long *module_map,
>       * mean that they will not accept microcode updates. We take the hint
>       * and ignore the microcode interface in that case.
>       */
> -    if ( this_cpu(cpu_sig).rev == ~0 )
> +    if ( this_cpu(cpu_sig).rev == ~0 || !can_load )

While not too bad, the addition brings code and comment slightly out
of sync.

> --- a/xen/arch/x86/cpu/microcode/intel.c
> +++ b/xen/arch/x86/cpu/microcode/intel.c
> @@ -385,6 +385,19 @@ static struct microcode_patch *cf_check 
> cpu_request_microcode(
>      return patch;
>  }
>  
> +bool __init intel_can_load_microcode(void)
> +{
> +    uint64_t mcu_ctrl;
> +
> +    if ( !cpu_has_mcu_ctrl )
> +        return true;
> +
> +    rdmsrl(MSR_MCU_CONTROL, mcu_ctrl);

While one would hope that feature bit and MSR access working come in
matched pairs, I still wonder whether - just to be on the safe side -
the caller wouldn't better avoid calling here when rev == ~0 (and
hence we won't try to load ucode anyway). I would envision can_load's
initializer to become this_cpu(cpu_sig).rev != ~0, with other logic
adjusted as necessary in early_microcode_init().

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.