From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: "Yu, Fenghua" <fenghua.yu@intel.com>
Cc: H Peter Anvin <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
"Mallick, Asit K" <asit.k.mallick@intel.com>,
Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
Andreas Herrmann <andreas.herrmann3@amd.com>,
Borislav Petkov <borislav.petkov@amd.com>,
linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH 04/11] x86/microcode_core_early.c: Define interfaces for early load ucode
Date: Sun, 19 Aug 2012 01:43:02 -0300 [thread overview]
Message-ID: <20120819044302.GB9773@khazad-dum.debian.net> (raw)
In-Reply-To: <3E5A0FA7E9CA944F9D5414FEC6C71220077879BF@ORSMSX105.amr.corp.intel.com>
On Sun, 19 Aug 2012, Yu, Fenghua wrote:
> > From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > On Sat, 18 Aug 2012, Fenghua Yu wrote:
> > > + char ucode_name[] =
> > "kernel/x86/microcode/GenuineIntel/microcode.hex";
> >
> > Why name it ".hex" when you're loading binary data? I suggest ".bin".
> > It
> > is confusing to have .hex there, since you're not dealing with the
> > Intel HEX
> > format, nor anything text-like.
> >
> > > +void __init load_ucode_bsp(char *real_mode_data)
> > > +{
> > > + u64 ramdisk_image, ramdisk_size, ramdisk_end;
> > > + unsigned long initrd_start, initrd_end;
> > > + struct boot_params *boot_params;
> > > +
> > > + boot_params = (struct boot_params *)real_mode_data;
> > > + ramdisk_image = boot_params->hdr.ramdisk_image;
> > > + ramdisk_size = boot_params->hdr.ramdisk_size;
> > > +
> > > +#ifdef CONFIG_X86_64
> > > + ramdisk_end = PAGE_ALIGN(ramdisk_image + ramdisk_size);
> > > + initrd_start = ramdisk_image + PAGE_OFFSET;
> > > +#else
> > > + ramdisk_end = ramdisk_image + ramdisk_size;
> > > + initrd_start = ramdisk_image;
> > > +#endif
> > > + initrd_end = initrd_start + ramdisk_size;
> > > +
> > > + /*
> > > + * It's early to get CPU vendor info at this point.
> > > + * By searching initrd to find right name for vendor's microcode,
> > > + * it's relative easier to get CPU vendor info.
> > > + */
> > > + if (find_ucode_intel(initrd_start, initrd_end) == UCODE_OK)
> > > + load_ucode_intel_bsp(real_mode_data);
> > > +}
> >
> > I'd say something down the load_ucode_intel_bsp() chain better check
> > the CPU
> > vendor to make sure the Intel driver won't attempt to load microcode on
> > some
> > other vendor's processor.
> >
> > Or are cpu signatures a global namespace and x86 cpu vendors make sure
> > (past, present and future) to never use the same cpu signature as
> > someone
> > else is going to use? Anyway, it would still might be a good thing to
> > do
> > the vendor check somewhere to avoid wasting time going over every
> > microcode
> > of the wrong vendor on generic boot images that have both AMD and Intel
> > microcode.
> >
>
> In this early phase, detecting vendor in initrd is much simpler code. Otherwise, detecting vendor by cpuid (and without cpuid) needs similar but different code as existing functions and coding would be awkward.
>
> I fully thought and agreed the usage complexity you describe here. It might be good thing to do a bit ugly but more practical coding here.
Sure, there is no harm in defering the implementation of this check to later
versions of the patch set. As long as the final patch set doesn't risk
loading microcode on the wrong vendor or waste a lot of milliseconds trying
to match intel microcode to a non-intel cpu, I have no objections :-)
But what about the ".hex" naming for the microcode bundle (container) name?
I find it confusing, since the file contains binary data, not structured
text representing binary data using base 16... this is also something that
is of minor importance, but at least it is a very easy thing to change at
this point.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2012-08-19 4:43 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-18 8:15 [PATCH 00/11] x86/microcode: Early load microcode Fenghua Yu
2012-08-18 8:15 ` [PATCH 01/11] Documentation/x86: " Fenghua Yu
2012-08-20 12:26 ` Borislav Petkov
2012-08-18 8:15 ` [PATCH 02/11] x86/lib/cpio.c: Find cpio data by its file name Fenghua Yu
2012-08-18 22:12 ` Henrique de Moraes Holschuh
2012-08-18 23:23 ` Yu, Fenghua
2012-08-19 4:35 ` Henrique de Moraes Holschuh
2012-08-19 5:15 ` H. Peter Anvin
2012-08-20 13:29 ` Borislav Petkov
2012-08-18 8:15 ` [PATCH 03/11] x86/microcode_intel.h: Define functions and macros for early load ucode Fenghua Yu
2012-08-20 13:47 ` Borislav Petkov
2012-08-18 8:15 ` [PATCH 04/11] x86/microcode_core_early.c: Define interfaces " Fenghua Yu
2012-08-18 22:44 ` Henrique de Moraes Holschuh
2012-08-19 2:38 ` Yu, Fenghua
2012-08-19 4:43 ` Henrique de Moraes Holschuh [this message]
2012-08-19 5:24 ` H. Peter Anvin
2012-08-19 16:39 ` Yu, Fenghua
2012-08-20 14:06 ` Borislav Petkov
2012-08-20 20:08 ` H. Peter Anvin
2012-08-20 20:19 ` Borislav Petkov
2012-08-21 20:05 ` Yu, Fenghua
2012-08-21 20:13 ` H. Peter Anvin
2012-08-21 20:48 ` Borislav Petkov
2012-08-21 20:52 ` H. Peter Anvin
2012-08-21 20:52 ` Yu, Fenghua
2012-08-21 20:53 ` H. Peter Anvin
2012-08-21 20:58 ` Yu, Fenghua
2012-08-20 14:04 ` Borislav Petkov
2012-08-18 8:15 ` [PATCH 05/11] x86/microcode_intel_lib.c: Early update ucode on Intel's CPU Fenghua Yu
2012-08-20 15:31 ` Borislav Petkov
2012-08-20 16:24 ` Borislav Petkov
2012-08-18 8:15 ` [PATCH 06/11] x86/microcode_intel_early.c: " Fenghua Yu
2012-08-18 8:15 ` [PATCH 07/11] x86/head_32.S: Early update ucode in 32-bit Fenghua Yu
2012-08-18 8:15 ` [PATCH 08/11] x86/head64.c: Early update ucode in 64-bit Fenghua Yu
2012-08-18 8:15 ` [PATCH 09/11] x86/smpboot.c: Early update ucode on AP Fenghua Yu
2012-08-18 8:15 ` [PATCH 10/11] x86/mm/init.c: Copy ucode from initrd image to memory Fenghua Yu
2012-08-18 8:15 ` [PATCH 11/11] x86/Kconfig: Configurations to enable/disable the feature Fenghua Yu
2012-08-20 21:41 ` Paul Bolle
2012-08-20 15:39 ` [PATCH 00/11] x86/microcode: Early load microcode Borislav Petkov
2012-08-20 15:44 ` Yu, Fenghua
2012-08-20 18:51 ` H. Peter Anvin
2012-08-20 20:04 ` 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=20120819044302.GB9773@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=andreas.herrmann3@amd.com \
--cc=asit.k.mallick@intel.com \
--cc=borislav.petkov@amd.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tigran@aivazian.fsnet.co.uk \
--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
all inboxes | Powered by JetHome®