public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Max Krasnyansky <maxk@qualcomm.com>
To: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Peter Oruba <peter.oruba@amd.com>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch 0/4] x86: AMD microcode patch loading v2 fixes
Date: Wed, 30 Jul 2008 09:35:32 -0700	[thread overview]
Message-ID: <48909854.2040201@qualcomm.com> (raw)
In-Reply-To: <b647ffbd0807300334q57cdca6fu474cc7b6bed36102@mail.gmail.com>



Dmitry Adamushko wrote:
> 2008/7/30 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>> 2008/7/30 Peter Oruba <peter.oruba@amd.com>:
>>>> [ ... ]
>>> Since ucode updates may fix severe issues, it is supposed to happen as early
>>> as possible. If you re-plug your CPU into your socket, your BIOS also
>>> applies a ucode patch, but that won't necessarily be the latest and critical
>>> one.
>> Hum, let's say we don't do it from cpu-hotplug handlers [1] but from
>> start_secondary() before calling cpu_idle()? [*]
>>
>> This way, we do it before any other task may have a chance to run on a
>> cpu which is not a case with cpu-hotplug handlers
>> (and we don't mess-up with cpu-hotplug events :-)
>>
>> [ the drawback is that 'microcode' subsystem is not local to
>> microcode.c anymore ]
>>
>> [1] if we need a sync. operation in cpu-hotplug handlers and IPI is
>> not ok (say, we need to run in a sleepablel context) then perhaps it's
>> workqueues + wait_on_cpu_work(). But then it's not a bit later than
>> could have been with [*].
>>
>> heh, this issue has already popped up in another thread so it should
>> be fixed asap, imho.
>>
>> Ingo, Peter? What would be the best way from your pov?
> 
> or let's just use smth like a patch below so far:
> 
> (non-white-space-damaged version is enclosed)
> 
> --- kernel/cpu.c-old    2008-07-30 12:31:15.000000000 +0200
> +++ kernel/cpu.c        2008-07-30 12:32:02.000000000 +0200
> @@ -349,6 +349,8 @@ static int __cpuinit _cpu_up(unsigned in
>                 goto out_notify;
>         BUG_ON(!cpu_online(cpu));
> 
> +       cpu_set(cpu, cpu_active_map);
> +
>         /* Now call notifier in preparation. */
>         raw_notifier_call_chain(&cpu_chain, CPU_ONLINE | mod, hcpu);
> 
> @@ -383,9 +385,6 @@ int __cpuinit cpu_up(unsigned int cpu)
> 
>         err = _cpu_up(cpu, 0);
> 
> -       if (cpu_online(cpu))
> -               cpu_set(cpu, cpu_active_map);
> -
>  out:
>         cpu_maps_update_done();
>         return err;

That was the first thing I thought of when you pointed out what the problem is
(ie when original bug report showed up).
But I immediately rejected the idea because it changes the rules of the game.
  active bit is set even before the cpu is "truly" online. I'd say we fix the
microcode instead.

Max




  reply	other threads:[~2008-07-30 16:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-29 15:41 [patch 0/4] x86: AMD microcode patch loading v2 fixes Peter Oruba
2008-07-29 15:41 ` [patch 1/4] x86: AMD microcode patch loader style corrections Peter Oruba
2008-07-29 15:41 ` [patch 2/4] x86: Intel " Peter Oruba
2008-07-29 15:41 ` [patch 3/4] x86: Moved function declarations out from AMD microcode patch loader to heade file Peter Oruba
2008-07-29 15:41 ` [patch 4/4] x86: Minor pointer type cast in AMD microcode patch loader Peter Oruba
2008-07-29 16:18 ` [patch 0/4] x86: AMD microcode patch loading v2 fixes Dmitry Adamushko
2008-07-29 17:49   ` Max Krasnyansky
2008-07-29 19:37     ` Dmitry Adamushko
2008-07-30  9:28     ` Peter Oruba
2008-07-30  9:57       ` Dmitry Adamushko
2008-07-30 10:34         ` Dmitry Adamushko
2008-07-30 16:35           ` Max Krasnyansky [this message]
2008-07-30 18:38             ` Dmitry Adamushko
2008-07-31 21:24               ` Ingo Molnar
2008-08-01  2:23                 ` Max Krasnyansky
2008-07-30 16:54         ` Max Krasnyansky
2008-07-30 20:59           ` Dmitry Adamushko
2008-08-01  2:18             ` Max Krasnyansky
2008-08-01 11:25       ` Dmitry Adamushko
2008-08-01 12:21         ` Peter Oruba
2008-08-01 15:26         ` H. Peter Anvin
2008-07-31 21:27 ` Ingo Molnar
2008-07-31 22:02   ` Dmitry Adamushko
2008-07-31 22:12     ` Ingo Molnar

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=48909854.2040201@qualcomm.com \
    --to=maxk@qualcomm.com \
    --cc=dmitry.adamushko@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peter.oruba@amd.com \
    --cc=tglx@linutronix.de \
    --cc=tigran@aivazian.fsnet.co.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox