kernel-packages team mailing list archive

[Tim Gardner <tim.gardner@xxxxxxxxxxxxx>]

Yingying - I believe policy will prevent intel-microcode from being
promoted to main since it contains a binary component that runs directly
on the host CPU.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1084373

Title:
  [Feature] Early load microcode for x86 CPU

Status in intel:
  New
Status in “linux” package in Ubuntu:
  Fix Committed
Status in “linux” source package in Utopic:
  Fix Committed

Bug description:
  The problem in current microcode loading method is that we load a
  microcode 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 AP's 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.

  Upstream schedule:
  Q4'12

To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1084373/+subscriptions