From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Borislav Petkov <bp@amd64.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
Peter Zijlstra <peterz@infradead.org>,
"Yu, Fenghua" <fenghua.yu@intel.com>, X86-ML <x86@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Andreas Herrmann <andreas.herrmann3@amd.com>
Subject: Re: [PATCH 2/2] x86, microcode: Make reload interface per system
Date: Fri, 22 Jun 2012 08:41:00 +0200 [thread overview]
Message-ID: <20120622064100.GA286@x4> (raw)
In-Reply-To: <20120622033634.GG29505@aftab.osrc.amd.com>
On 2012.06.22 at 05:36 +0200, Borislav Petkov wrote:
> On Thu, Jun 21, 2012 at 08:19:04PM -0700, H. Peter Anvin wrote:
> > On 06/21/2012 07:56 PM, Borislav Petkov wrote:
> > >>
> > >> That is orthogonal. Anyway, my only concern about the request_firmware
> > >> interface is that the timing will be inherently wrong.
> > >
> > > Timing? Please elaborate.
> > >
> >
> > The request_firmware will happen as soon as the driver is loaded; with
> > the early microcode blob scheme the driver will need to be built in and
> > so the request_firmware will happen, redundantly, immediately...
>
> What if BIOS has patch version 1 (numbers are only for showing what I
> mean), then early scheme applies patch v2 but there is a newer patch
> version 3 in /lib/firmware?
>
> If the ucode driver is built in, we don't get to update to v3
> automatically. User has to do it.
>
> The current fix for this situation is have the microcode.ko as module
> (and only allow it as M) which then automatically does request_firmware
> at module init time and loads v3.
>
> Which doesn't help people who don't build modules...
People who don't use modules have:
echo -n 1 > /sys/devices/system/cpu/cpu0/microcode/reload
...
in their init script already.
That will have to change to a single:
echo -n 1 >| /sys/devices/system/cpu/microcode/reload
in your new scheme.
Of course the best solution would be to get rid of that manual reload
altogether and to automatically load the firmware during boot (even
without modules)...
--
Markus
next prev parent reply other threads:[~2012-06-22 6:41 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 16:03 [PATCH 0/2] x86, microcode: Reload ucode only per-system Borislav Petkov
2012-06-19 16:03 ` [PATCH 1/2] x86, microcode: Sanitize per-cpu microcode reloading interface Borislav Petkov
2012-06-19 18:25 ` Henrique de Moraes Holschuh
[not found] ` <CANDHA0iu+QtQn=UxjpN34U=Ob4ABkZc4VWpPT5EidAgZm59JJQ@mail.gmail.com>
2012-06-19 23:15 ` Yu, Fenghua
2012-06-19 23:38 ` Borislav Petkov
2012-06-19 16:03 ` [PATCH 2/2] x86, microcode: Make reload interface per system Borislav Petkov
2012-06-19 18:26 ` Henrique de Moraes Holschuh
[not found] ` <CANDHA0jf2fLOtg1E6CbyNM=omn=kj=YoRJ3VTkNA0AhkS-MLtg@mail.gmail.com>
2012-06-19 23:10 ` Yu, Fenghua
2012-06-19 23:28 ` Borislav Petkov
2012-06-20 3:26 ` Henrique de Moraes Holschuh
2012-06-20 9:57 ` Borislav Petkov
2012-06-20 23:10 ` Henrique de Moraes Holschuh
2012-06-20 8:59 ` Peter Zijlstra
2012-06-20 9:56 ` Borislav Petkov
2012-06-20 10:08 ` Peter Zijlstra
2012-06-20 10:19 ` Borislav Petkov
2012-06-20 10:22 ` Peter Zijlstra
2012-06-20 10:27 ` Borislav Petkov
2012-06-20 10:33 ` Peter Zijlstra
2012-06-20 11:09 ` Borislav Petkov
2012-06-22 18:57 ` H. Peter Anvin
2012-06-23 1:54 ` Henrique de Moraes Holschuh
2012-06-23 2:26 ` H. Peter Anvin
2012-06-20 23:21 ` Henrique de Moraes Holschuh
2012-06-20 23:26 ` Borislav Petkov
2012-06-22 16:26 ` Nix
2012-06-22 18:21 ` H. Peter Anvin
2012-06-23 1:32 ` Henrique de Moraes Holschuh
2012-06-20 23:08 ` Henrique de Moraes Holschuh
2012-06-20 23:10 ` H. Peter Anvin
2012-06-20 23:23 ` Borislav Petkov
2012-06-20 23:27 ` H. Peter Anvin
2012-06-20 23:32 ` Borislav Petkov
2012-06-20 23:34 ` H. Peter Anvin
2012-06-20 23:46 ` Borislav Petkov
2012-06-20 23:48 ` H. Peter Anvin
2012-06-21 10:07 ` Borislav Petkov
2012-06-21 23:27 ` H. Peter Anvin
2012-06-22 2:56 ` Borislav Petkov
2012-06-22 3:19 ` H. Peter Anvin
2012-06-22 3:36 ` Borislav Petkov
2012-06-22 6:41 ` Markus Trippelsdorf [this message]
2012-06-20 23:59 ` Henrique de Moraes Holschuh
2012-06-20 23:50 ` Henrique de Moraes Holschuh
2012-06-21 0:02 ` Henrique de Moraes Holschuh
2012-06-21 8:24 ` Peter Zijlstra
2012-06-21 9:58 ` Borislav Petkov
2012-06-21 23:28 ` H. Peter Anvin
2012-06-21 23:00 ` Henrique de Moraes Holschuh
2012-06-22 3:01 ` Borislav Petkov
2012-06-20 13:18 ` Borislav Petkov
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=20120622064100.GA286@x4 \
--to=markus@trippelsdorf.de \
--cc=andreas.herrmann3@amd.com \
--cc=bp@amd64.org \
--cc=fenghua.yu@intel.com \
--cc=hmh@hmh.eng.br \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox