All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: linux-kernel@vger.kernel.org,
	Dmitry Adamushko <dmitry.adamushko@gmail.com>,
	Hugh Dickins <hugh@veritas.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] microcode: do not WARN_ON(cpu != 0) during resume
Date: Thu, 17 Dec 2009 10:45:36 -0800	[thread overview]
Message-ID: <4B2A7C50.5080403@goop.org> (raw)
In-Reply-To: <1261058024-32278-1-git-send-email-ian.campbell@citrix.com>

On 12/17/2009 05:53 AM, Ian Campbell wrote:
> 871b72dd "x86: microcode: use smp_call_function_single instead of
> set_cpus_allowed, cleanup of synchronization logic" included:
>
>   static int mc_sysdev_resume(struct sys_device *dev)
>   {
> [...]
> +       /*
> +        * All non-bootup cpus are still disabled,
> +        * so only CPU 0 will apply ucode here.
> +        *
> +        * Moreover, there can be no concurrent
> +        * updates from any other places at this point.
> +        */
> +       WARN_ON(cpu != 0);
>
> However suspend/resume under Xen doesn't need to hot unplug all the CPUs, so we
> don't; the hypervisor can manage the context save/restore for all CPUs.
>    

Did you see a problem with this in practice, or just by inspection?

The Xen microcode driver will only load in a privileged domain, so I 
don't think this path can ever be exercised.

Regardless, the Xen microcode driver changes aren't upstream yet, so 
there's no need to apply this there yet.

Thanks,
     J

> It would be unnecessary to load microcode.ko in a Xen domU but if it does occur
> (e.g. because a distro installs the tools by default) we would like to avoid
> the warning on resume.
>
> Since the real constraint here is that we are running on the CPU for which we
> would like to load microcode (which in all practical circumstances is CPU0)
> just check for that and return if we are resuming a different CPU.
>
> There is no danger of concurrent updates, even if we ignore the fact that all
> but one CPUs are unplugged on native, because sysdev_resume() is single
> threaded.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> Cc: Dmitry Adamushko<dmitry.adamushko@gmail.com>
> Cc: Hugh Dickins<hugh@veritas.com>
> Cc: Ingo Molnar<mingo@elte.hu>
> ---
>   arch/x86/kernel/microcode_core.c |   11 +----------
>   1 files changed, 1 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
> index 378e9a8..1153062 100644
> --- a/arch/x86/kernel/microcode_core.c
> +++ b/arch/x86/kernel/microcode_core.c
> @@ -438,18 +438,9 @@ static int mc_sysdev_resume(struct sys_device *dev)
>   	int cpu = dev->id;
>   	struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
>
> -	if (!cpu_online(cpu))
> +	if (cpu != smp_processor_id())
>   		return 0;
>
> -	/*
> -	 * All non-bootup cpus are still disabled,
> -	 * so only CPU 0 will apply ucode here.
> -	 *
> -	 * Moreover, there can be no concurrent
> -	 * updates from any other places at this point.
> -	 */
> -	WARN_ON(cpu != 0);
> -
>   	if (uci->valid&&  uci->mc)
>   		microcode_ops->apply_microcode(cpu);
>
>    


  reply	other threads:[~2009-12-17 18:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-17 13:53 [PATCH] microcode: do not WARN_ON(cpu != 0) during resume Ian Campbell
2009-12-17 18:45 ` Jeremy Fitzhardinge [this message]
2009-12-18  9:07   ` Ian Campbell
2009-12-18 16:43     ` Jeremy Fitzhardinge
2011-02-04 12:59 ` Anton Arapov

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=4B2A7C50.5080403@goop.org \
    --to=jeremy@goop.org \
    --cc=dmitry.adamushko@gmail.com \
    --cc=hugh@veritas.com \
    --cc=ian.campbell@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.