Re: [PATCH v4 00/11] x86/microcode: Early load microcode

2012-12-21 Thread Borislav Petkov
On Fri, Dec 21, 2012 at 03:09:48PM +, Yu, Fenghua wrote:
> > Why loading microcode this early is important? Why it is bad to load
> > it at the end of (initial) boot?
> >
> If not loading microcode early, we may hit some issues (e.g. PSE on
> Atom) and disable some CPU features. These issues can not be fixed by
> loading ucode during run time.

This question keeps popping up with this patchset, maybe you could
enlarge the first paragraph of Documentation/x86/early-microcode.txt
with a bit more detail and examples.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH v4 00/11] x86/microcode: Early load microcode

2012-12-21 Thread Yu, Fenghua
> -Original Message-
> From: Michael Tokarev [mailto:m...@tls.msk.ru]
> Sent: Friday, December 21, 2012 1:05 AM
> To: Yu, Fenghua
> Cc: H Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K;
> Tigran Aivazian; Yinghai Lu; Andreas Herrmann; Borislav Petkov; linux-
> kernel; x86
> Subject: Re: [PATCH v4 00/11] x86/microcode: Early load microcode
> 
> On 20.12.2012 23:48, Fenghua Yu wrote:
> > From: Fenghua Yu 
> >
> > The problem in current microcode loading method is that we load a
> microcode way,
> > way too late; ideally we should load it before turning paging on.
> This may only
> > be practical on 32 bits since we can't get to 64-bit mode without
> paging on,
> > but we should still do it as early as at all possible.
> 
> Why loading microcode this early is important?
> Why it is bad to load it at the end of (initial) boot?
> 
> Thanks,
> 
> /mjt

If not loading microcode early, we may hit some issues (e.g. PSE on Atom) and 
disable some CPU features. These issues can not be fixed by loading ucode 
during run time.

Thanks.

-Fenghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v4 00/11] x86/microcode: Early load microcode

2012-12-21 Thread Michael Tokarev
On 20.12.2012 23:48, Fenghua Yu wrote:
> From: Fenghua Yu 
> 
> The problem in current microcode loading method is that we load a microcode 
> way,
> way too late; ideally we should load it before turning paging on.  This may 
> only
> be practical on 32 bits since we can't get to 64-bit mode without paging on,
> but we should still do it as early as at all possible.

Why loading microcode this early is important?
Why it is bad to load it at the end of (initial) boot?

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v4 00/11] x86/microcode: Early load microcode

2012-12-20 Thread Fenghua Yu
From: Fenghua Yu 

The problem in current microcode loading method is that we load a microcode way,
way too late; ideally we should load it before turning paging on.  This may only
be practical on 32 bits since we can't get to 64-bit mode without paging on,
but we should still do it as early as at all possible.

Similarly, we should load the microcode update as early as possible during AP
bringup and when processors are brought back online after hotplug or S3/S4.

In order to do that, the microcode patch needs to be permanently present in
kernel memory.  Each individual patch is fairly small, so that is OK, but the
entire blob with support for each CPU is too big. Since only CPU's with same
model can be in the same platform, we store microcode with the same model as
BSP. Later on APs can upload microcode from the saved microcodep patches.

Note, however, that Linux users have gotten used to being able to install a
microcode patch in the field without having a reboot; we support that model too.

In x86_64, this patchset needs early #PF handler set page table patchset. So
this patchset is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git 
for-x86-boot

v4: Change CPUID_IS macro. Call load_ucode_bsp after load_idt in x86_64. Flush
tlb after applying microcode.

v3: Change .hex to .bin in 01/10 and 05/10 patches. Fix some compilation
warnings. In x86_32 mode, access global varialbes by __pa_symobl() and fix
static string issue in x86_vendor(). Call load_ucode_ap() in real mode as well.
Add debug info.

v2: Detect vendor before loading microcode. Move some functions from
microcode_intel_early.c to microcode_intel_lib.c. Change some early loading
microcode dependencies in Kconfig. Reword doc.

Fenghua Yu (11):
  Documentation/x86: Early load microcode
  x86/microcode_intel.h: Define functions and macros for early loading
ucode
  x86/common.c: Make have_cpuid_p() a global function
  x86/microcode_core_early.c: Define interfaces for early loading ucode
  x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
  x86/tlbflush.h: Define __native_flush_tlb_global_irq_disabled()
  x86/microcode_intel_early.c: Early update ucode on Intel's CPU
  x86/head_32.S: Early update ucode in 32-bit
  x86/head64.c: Early update ucode in 64-bit
  x86/mm/init.c: Copy ucode from initrd image to kernel memory
  x86/Kconfig: Configurations to enable/disable the feature

 Documentation/x86/early-microcode.txt   |  43 ++
 arch/x86/Kconfig|  18 +
 arch/x86/include/asm/microcode.h|  14 +
 arch/x86/include/asm/microcode_intel.h  |  85 
 arch/x86/include/asm/processor.h|   8 +
 arch/x86/include/asm/tlbflush.h |  18 +-
 arch/x86/kernel/Makefile|   3 +
 arch/x86/kernel/cpu/common.c|  17 +-
 arch/x86/kernel/head64.c|   6 +
 arch/x86/kernel/head_32.S   |  12 +
 arch/x86/kernel/microcode_core.c|   7 +-
 arch/x86/kernel/microcode_core_early.c  |  76 +++
 arch/x86/kernel/microcode_intel.c   | 198 ++--
 arch/x86/kernel/microcode_intel_early.c | 792 
 arch/x86/kernel/microcode_intel_lib.c   | 174 +++
 arch/x86/mm/init.c  |  10 +
 16 files changed, 1298 insertions(+), 183 deletions(-)
 create mode 100644 Documentation/x86/early-microcode.txt
 create mode 100644 arch/x86/include/asm/microcode_intel.h
 create mode 100644 arch/x86/kernel/microcode_core_early.c
 create mode 100644 arch/x86/kernel/microcode_intel_early.c
 create mode 100644 arch/x86/kernel/microcode_intel_lib.c

-- 
1.8.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/