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

Re: [PATCH 1/2] x86/ucode: Move vendor specifics back out of early_microcode_init()


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 26 Oct 2023 09:45:30 +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=wGVaZJl990xqzRXMv5PLviGMafAstKUXR/YKeKebAIU=; b=Oa3hHomwt3Xmhqq/MZs+osVumwemM8IHRCTyQLoz7ODNF3x1XPEIh+Z1POg+fNdRFWC4FyfWEPs60QDTxLJFkYouJDh/8T3oOjSlQ9mNsG92qOMdZ39KfYcSXdsNiICCUzY6n0EXjiy/qcNC+XT9KSD3m7Cs0bVd1JQT4E351zyrjlaOAW2G+ccnLKTM6zGdt2UdTbnPCqPRyBsJQX4G9mywh6/b/uEeh/n/f5+awi5i0i6lPByivVUK6tdckocTbkhXnngb3kKgLjmQjDk9HsuJeqxpMf2l7tBqSwK/QhamUf8u5FCvkcIIEEVYxFg1f6BnVKm4G38KkEmd5F/1xA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZWXBWYyIIShx22jUSjnoXnab9lNuioRKjq0SJ/aNhCixkvQ3TtJmM01sKUxzB4fMgWL3dtwPyKeU/561cXROUlsl0ZDlgV0rL8L+xmKqvvu48Yf5h+sWs0h/7f2d1X5iQ/cNM0vjSJr53fJnTJGXekaMtIFNIsCLM1iodxhPC7E+QNf7IOauxkpWAot1rfvljR8QduzvCOl8qYhLbnVBGFfx0PjxjEgoo0DVkmu1Anhc1X/Tl4W5q5GMNzif1yX785tu1hhZGUtdpOmHui8bhmsHh0nS4i+77E+oSSv1fiNojqnLLp8mBjhMHBOqzMVLVtRX59NjeyoQKT6b77LRhQ==
  • 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>, Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 26 Oct 2023 07:45:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25.10.2023 20:06, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -847,25 +847,19 @@ 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;
> -        }
> +        ucode_probe_amd(&ucode_ops);
>          break;
>  
>      case X86_VENDOR_INTEL:
> -        ucode_ops = intel_ucode_ops;
> -        can_load = intel_can_load_microcode();
> +        ucode_probe_intel(&ucode_ops);
>          break;
>      }
>  
> -    if ( !ucode_ops.apply_microcode )
> +    if ( !ucode_ops.collect_cpu_info )
>      {
>          printk(XENLOG_INFO "Microcode loading not available\n");
>          return -ENODEV;
> @@ -882,10 +876,10 @@ int __init early_microcode_init(unsigned long 
> *module_map,
>       *
>       * Take the hint in either case and ignore the microcode interface.
>       */
> -    if ( this_cpu(cpu_sig).rev == ~0 || !can_load )
> +    if ( !ucode_ops.apply_microcode || this_cpu(cpu_sig).rev == ~0 )

Here ucode_ops.apply_microcode simply replaces can_load, as expected.

>      {
>          printk(XENLOG_INFO "Microcode loading disabled due to: %s\n",
> -               can_load ? "rev = ~0" : "HW toggle");
> +               ucode_ops.apply_microcode ? "HW toggle" : "rev = ~0");

Here, otoh, you invert sense, which I don't think is right. With 2nd
and 3rd operands swapped back
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> @@ -398,9 +398,17 @@ bool __init intel_can_load_microcode(void)
>      return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD);
>  }
>  
> -const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = {
> +static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops = {
>      .cpu_request_microcode            = cpu_request_microcode,
>      .collect_cpu_info                 = collect_cpu_info,
>      .apply_microcode                  = apply_microcode,
>      .compare_patch                    = compare_patch,
>  };
> +
> +void __init ucode_probe_intel(struct microcode_ops *ops)
> +{
> +    *ops = intel_ucode_ops;
> +
> +    if ( !can_load_microcode() )
> +        ops->apply_microcode = NULL;
> +}

I was wondering why you didn't use the return value to supply the pointer
to the caller, but this override explains it.

Jan



 


Rackspace

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