public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <borislav.petkov@amd.com>
To: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Mike Travis <travis@sgi.com>,
	Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andreas Mohr <andi@lisas.de>, Jack Steiner <steiner@sgi.com>
Subject: Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages
Date: Thu, 12 Nov 2009 18:09:39 +0100	[thread overview]
Message-ID: <20091112170939.GA31660@aftab> (raw)
In-Reply-To: <b647ffbd0911120748q6e3ddcf9h31b48972aff9e39c@mail.gmail.com>

On Thu, Nov 12, 2009 at 04:48:34PM +0100, Dmitry Adamushko wrote:
> request_firmware_nowait() sends an async request which can be
> preserved (and this is an assumption -- I haven't really verified it
> yet) until some latter stage when user-space has been started and is
> capable of handling (cached) firmware-load requests. I may be (and
> perhaps I'm) wrong with the above assumption and the solution is
> either never build such a module into the kernel or only do it with
> built-in firmware blobs.

I don't think built-in blobs is the way we want to go here - in that
case updating the microcode would require rebuilding the kernel, which
is a clear overkill and exactly the opposite of what we should be doing.
Imagine a big supercomputer consisting of several thousand nodes, all
with identical CPUs. Now, everytime there's microcode patch available,
you have to reboot all those machines after having distributed the
updated kernel images just so that all nodes have their microcode
updated. Many admins would go: "Hmm, no!"

What actually got somehow dropped from Andreas' patch and which we
talked about and agreed upon earlier is that the best thing to do would
be to do

$ rmmod microcode
$ modprobe microcode

after having copied the new ucode patch to /lib/firmware without
disturbing the machine execution.

The async _nowait() version sounds good but in that case you're still
going to need to trigger the microcode update somehow (and AFAIK there's
no mechanism for that yet.) So reloading the module is the easiest thing
and it doesn't need any code changes except the Kconfig oneliner.

Hmm...

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632


  reply	other threads:[~2009-11-12 17:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-02 20:08 [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages dimm
2009-11-04 12:27 ` Ingo Molnar
2009-11-05 15:37 ` Andreas Herrmann
2009-11-05 18:40   ` Dmitry Adamushko
2009-11-06 12:34     ` Andreas Herrmann
2009-11-06 12:56       ` Dmitry Adamushko
2009-11-06 19:46         ` Andreas Herrmann
2009-11-07 12:22           ` Dmitry Adamushko
2009-11-11 16:07             ` Dmitry Adamushko
2009-11-11 19:38               ` Andreas Herrmann
2009-11-12 11:33                 ` Ingo Molnar
2009-11-12 11:54                   ` Dmitry Adamushko
2009-11-12 12:06                     ` Dmitry Adamushko
2009-11-12 15:20                       ` Andreas Herrmann
2009-11-12 15:48                         ` Dmitry Adamushko
2009-11-12 17:09                           ` Borislav Petkov [this message]
2009-11-17  7:06                   ` [PATCH] x86, ucode-amd: Move family check to microcde_amd.c's init function Andreas Herrmann
2009-11-17  9:24                     ` [tip:x86/microcode] x86: " tip-bot for Andreas Herrmann

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=20091112170939.GA31660@aftab \
    --to=borislav.petkov@amd.com \
    --cc=andi@lisas.de \
    --cc=dmitry.adamushko@gmail.com \
    --cc=herrmann.der.user@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=tigran@aivazian.fsnet.co.uk \
    --cc=travis@sgi.com \
    /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