Re: Linux Kernel Microcode Question

From: Tigran Aivazian (tigran_at_veritas.com)
Date: 03/18/04

  • Next message: Andy Whitcroft: "Re: [Lse-tech] Re: Hugetlbpages in very large memory machines......."
    Date:	Thu, 18 Mar 2004 22:20:07 +0000 (GMT)
    To: Justin Piszcz <jpiszcz@hotmail.com>
    
    

    Hi Justin,

    The answer to your question is that some Intel CPUs (just like any other
    hardware or software) contain bugs and, fortunately, their architecture is
    flexible enough to provide a way to fix those bugs by means of loading the
    microcode update on the fly, i.e. while the OS is running with no need
    to reboot (in fact, rebooting or otherwise resetting the CPU causes the
    update to be lost and requires to run the update again).

    This is the advantage. There are no disadvantages. After the microcode
    update has been loaded into the CPUs, the microcode driver can be removed
    to save a tiny amount of memory that it takes:

    # rmmod microcode

    Yes, it does matter which Intel CPUs you have. The driver selects the
    appropriate chunk of microcode for every CPU present on the system and
    loads it accordingly. You may even have mixed CPUs (i.e. of different
    kind) in an SMP system and this is handled automatically.

    Kind regards
    Tigran

    On Thu, 18 Mar 2004, Justin Piszcz wrote:

    > The URL: http://www.urbanmyth.org/microcode/
    >
    > The microcode_ctl utility is a companion to the IA32 microcode driver
    > written by Tigran Aivazian <tigran@veritas.com>. The utility has two uses:
    >
    > * it decodes and sends new microcode to the kernel driver to be uploaded
    > to Intel IA32 processors. (Pentium Pro, PII, PIII, Pentium 4, Celeron, Xeon
    > etc - all P6 and above, which does NOT include pentium classics)
    > * it signals the kernel driver to release any buffers it may hold
    >
    > The microcode update is volatile and needs to be uploaded on each system
    > boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts
    > back to the old microcode.
    >
    > My question is, what are the advantages vs disadvantages in updating your
    > CPU's microcode?
    >
    > Is it worth it?
    >
    > Does it matter what type of Intel CPU you have?
    >
    > Do some CPU's benefit more than others for microcode updates?
    >
    > I know RedHat distributions usually do this by default, but others do not.
    >
    > Can anyone explain reasons to or not to update the CPU microcode?
    >
    > _________________________________________________________________
    > FREE pop-up blocking with the new MSN Toolbar – get it now!
    > http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >

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


  • Next message: Andy Whitcroft: "Re: [Lse-tech] Re: Hugetlbpages in very large memory machines......."

    Relevant Pages

    • Re: [PATCH 2/2] microcode update driver rewrite
      ... way we could split ucode file as small one. ... such as selectively update and validate microcode for specific models, ... One is 'version' which shows current ucode version of CPU. ... script should be changed to just loading the driver without unloading ...
      (Linux-Kernel)
    • Re: rdmsr from userspace
      ... I don't like interface of that device, I think that ioctl approach would be preferable in this case. ... While I think this is good for testing and development, I prefer having a device driver to handle that specific MSR than a generic /dev/cpuN where you can issue MSRs. ... CPU tweaking for bugs workaround without patching the kernel; ... Regarding to your two last points, I would prefer to have a microcode driver than a microcode userland utility that relies on devcpu. ...
      (freebsd-hackers)
    • Re: How does this make you feel?
      ... >>>primitives to implement, say, a memcpy just as efficiently as microcode ... > The work is offloaded from the programmer in any case - this type of code ... library macros need updating for new CPU products, ... And designing such instruction such that they don't ...
      (comp.arch)
    • [patch 10/11] [PATCH 10/11] x86: Major refactoring.
      ... However, that is exclusive, there is only one vendor specific module ... A CPU vendor check makes sure only the corect ... you will be able to update the microcode on ... static void microcode_init_cpu ...
      (Linux-Kernel)
    • Re: Perpetual re:booting
      ... Prescott processors on boards which do not fully support them. ... the processor microcode is not updating correctly. ... allow the machine to boot up with whatever microcode update the BIOS has ... The microcode version is identified by this utility as "CPU Revision" ...
      (microsoft.public.windowsxp.accessibility)