All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Chao Gao <chao.gao@intel.com>
Cc: xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v4 4/6] microcode: don't call apply_microcode() in cpu_request_microcode()
Date: Wed, 28 Nov 2018 16:02:25 +0100	[thread overview]
Message-ID: <20181128150225.4axdecgu33xlwwzu@mac> (raw)
In-Reply-To: <1543383256-12371-5-git-send-email-chao.gao@intel.com>

On Wed, Nov 28, 2018 at 01:34:14PM +0800, Chao Gao wrote:
> cpu_request_microcode() will only parse microcode file and save
> suitable microcodes to microcode_cache. To update microcode,
> apply_microcode() should be invoked explicitly.
> 
> On AMD side, svm_host_osvw_init() is supposed to be called after
> microcode update. As apply_micrcode() won't be called by
> cpu_request_microcode() now, svm_host_osvw_init() is also moved to the
> end of apply_microcode().

I don't understand the previous usage of cpu_request_microcode, was it
used to update the microcode? The name seems to suggest it's used to
get a microcode version without applying anything to the CPU.

> 
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> ---
>  xen/arch/x86/microcode.c       | 58 ++++++++++++++++++++++++++++++------------
>  xen/arch/x86/microcode_amd.c   | 15 +++++------
>  xen/arch/x86/microcode_intel.c |  5 +---
>  3 files changed, 50 insertions(+), 28 deletions(-)
> 
> diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
> index 8350d22..cca7b2c 100644
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -233,20 +233,12 @@ int microcode_resume_cpu(unsigned int cpu)
>      return err;
>  }
>  
> -static int microcode_update_cpu(const void *buf, size_t size)
> +static int microcode_update_cpu(void)
>  {
>      int err;
> -    unsigned int cpu = smp_processor_id();
> -    struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
>  
>      spin_lock(&microcode_mutex);
> -
> -    err = microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
> -    if ( likely(!err) )
> -        err = microcode_ops->cpu_request_microcode(cpu, buf, size);
> -    else
> -        __microcode_fini_cpu(cpu);
> -
> +    err = microcode_ops->apply_microcode(smp_processor_id());
>      spin_unlock(&microcode_mutex);
>  
>      return err;
> @@ -259,7 +251,7 @@ static long do_microcode_update(void *_info)
>  
>      BUG_ON(info->cpu != smp_processor_id());
>  
> -    error = microcode_update_cpu(info->buffer, info->buffer_size);
> +    error = microcode_update_cpu();

Why don't you just set info->error = microcode_update_cpu()?

AFAICT this is done to attempt to update the remaining CPUs if one
update failed?

Is there anyway to rollback to the previous state so all CPUs have the
same microcode? I assume nothing good will come out of running a
system with CPUs using different microcode versions, but maybe that's
not so bad?

>      if ( error )
>          info->error = error;
>  
> @@ -276,6 +268,8 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
>  {
>      int ret;
>      struct microcode_info *info;
> +    unsigned int cpu = smp_processor_id();
> +    struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
>  
>      if ( len != (uint32_t)len )
>          return -E2BIG;
> @@ -294,10 +288,6 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
>          return ret;
>      }
>  
> -    info->buffer_size = len;
> -    info->error = 0;
> -    info->cpu = cpumask_first(&cpu_online_map);
> -
>      if ( microcode_ops->start_update )
>      {
>          ret = microcode_ops->start_update();
> @@ -308,6 +298,26 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
>          }
>      }
>  
> +    spin_lock(&microcode_mutex);
> +
> +    ret = microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
> +    if ( likely(!ret) )
> +        ret = microcode_ops->cpu_request_microcode(cpu, info->buffer, len);
> +    else
> +        __microcode_fini_cpu(cpu);
> +
> +    spin_unlock(&microcode_mutex);

Why do you need to hold the lock here?

microcode_update is already serialized and should only be executed on
a CPU at a time due to the usage of chained
continue_hypercall_on_cpu.

> +
> +    if ( ret <= 0 )
> +    {
> +        printk("No valid or newer microcode found. Update abort!\n");
> +        return -EINVAL;
> +    }
> +
> +    info->buffer_size = len;
> +    info->error = 0;
> +    info->cpu = cpumask_first(&cpu_online_map);
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> @@ -370,13 +380,29 @@ int __init early_microcode_update_cpu(bool start_update)
>      }
>      if ( data )
>      {
> +        unsigned int cpu = smp_processor_id();
> +        struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
> +
>          if ( start_update && microcode_ops->start_update )
>              rc = microcode_ops->start_update();
>  
>          if ( rc )
>              return rc;
>  
> -        return microcode_update_cpu(data, len);
> +        spin_lock(&microcode_mutex);
> +
> +        rc = microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
> +        if ( likely(!rc) )
> +            rc = microcode_ops->cpu_request_microcode(cpu, data, len);
> +        else
> +            __microcode_fini_cpu(cpu);
> +
> +        spin_unlock(&microcode_mutex);
> +
> +        if ( rc <= 0 )
> +            return -EINVAL;
> +
> +        return microcode_update_cpu();
>      }
>      else
>          return -ENOMEM;
> diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
> index 6e6598a..6d860f3 100644
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -299,6 +299,10 @@ static int apply_microcode(unsigned int cpu)
>  
>      uci->cpu_sig.rev = rev;
>  
> +#if CONFIG_HVM
> +    svm_host_osvw_init();
> +#endif
> +
>      return 0;
>  }
>  
> @@ -466,6 +470,7 @@ static int cpu_request_microcode(unsigned int cpu, const void *buf,
>      struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
>      unsigned int current_cpu_id;
>      unsigned int equiv_cpu_id;
> +    unsigned int matched_cnt = 0;
>  
>      /* We should bind the task to the CPU */
>      BUG_ON(cpu != raw_smp_processor_id());
> @@ -572,9 +577,7 @@ static int cpu_request_microcode(unsigned int cpu, const void *buf,
>  
>          if ( microcode_fits(mc_amd, cpu) )
>          {
> -            error = apply_microcode(cpu);
> -            if ( error )
> -                break;
> +            matched_cnt++;
>              applied_offset = last_offset;
>          }
>  
> @@ -609,17 +612,13 @@ static int cpu_request_microcode(unsigned int cpu, const void *buf,
>      }
>  
>    out:
> -#if CONFIG_HVM
> -    svm_host_osvw_init();
> -#endif
> -
>      /*
>       * In some cases we may return an error even if processor's microcode has
>       * been updated. For example, the first patch in a container file is loaded
>       * successfully but subsequent container file processing encounters a
>       * failure.
>       */
> -    return error;
> +    return !error ? matched_cnt : error;

You can use error ?: matched_cnt; which is shorter.

>  }
>  
>  static int start_update(void)
> diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
> index 1857332..a529623 100644
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -466,10 +466,7 @@ static int cpu_request_microcode(unsigned int cpu, const void *buf,
>      if ( offset < 0 )
>          error = offset;
>  
> -    if ( !error && matching_count )
> -        error = apply_microcode(cpu);
> -
> -    return error;
> +    return !error ? matching_count : error;

Same here.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-11-28 15:05 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28  5:34 [PATCH v4 0/6] improve late microcode loading Chao Gao
2018-11-28  5:34 ` [PATCH v4 1/6] microcode/intel: extend microcode_update_match() Chao Gao
2018-11-28 10:58   ` Roger Pau Monné
2018-11-29  2:00     ` Chao Gao
2018-11-29  9:14       ` Roger Pau Monné
2018-11-28  5:34 ` [PATCH v4 2/6] microcode: save all microcodes which pass sanity check Chao Gao
2018-11-28 12:00   ` Roger Pau Monné
2018-11-29  2:40     ` Chao Gao
2018-11-29  9:22       ` Roger Pau Monné
2018-11-30  7:55         ` Chao Gao
2018-11-30  9:32           ` Jan Beulich
2019-01-15 15:07             ` Andrew Cooper
2018-12-04 22:39         ` Woods, Brian
2018-12-05  7:38           ` Chao Gao
2018-11-29 10:19       ` Jan Beulich
2019-01-15 15:15         ` Andrew Cooper
2018-11-28  5:34 ` [PATCH v4 3/6] microcode: delete 'mc' field from struct ucode_cpu_info Chao Gao
2018-11-28 12:32   ` Roger Pau Monné
2018-11-28  5:34 ` [PATCH v4 4/6] microcode: don't call apply_microcode() in cpu_request_microcode() Chao Gao
2018-11-28 15:02   ` Roger Pau Monné [this message]
2018-11-29  4:28     ` Chao Gao
2018-11-29  9:46       ` Roger Pau Monné
2018-11-30  8:57         ` Chao Gao
2018-11-30  9:38           ` Jan Beulich
2018-11-28  5:34 ` [PATCH v4 5/6] microcode: delete microcode pointer and size from microcode_info Chao Gao
2018-11-28 15:04   ` Roger Pau Monné
2018-11-28  5:34 ` [PATCH v4 6/6] x86/microcode: Synchronize late microcode loading Chao Gao
2018-11-28 15:22   ` Roger Pau Monné
2018-11-29  4:43     ` Chao Gao
2018-11-29  9:56       ` Roger Pau Monné
2018-11-29 22:43         ` Boris Ostrovsky
2018-11-30  9:46           ` Jan Beulich
2018-11-30 16:49             ` Boris Ostrovsky
2018-11-30  9:01         ` Chao Gao
2019-01-15 15:24           ` Andrew Cooper
2019-01-15 16:24             ` Roger Pau Monné
2018-12-11 17:01   ` Jan Beulich
2018-12-11 18:16     ` Raj, Ashok
2018-12-12  7:26       ` Jan Beulich
2018-12-13  2:10         ` Boris Ostrovsky
2018-12-12  4:53     ` Chao Gao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181128150225.4axdecgu33xlwwzu@mac \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=chao.gao@intel.com \
    --cc=jbeulich@suse.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.