All of lore.kernel.org
 help / color / mirror / Atom feed
From: Burt Triplett <burt@pbjtriplett.org>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: x86/microcode: intel: correctly handle negative revisions
Date: Fri, 25 Mar 2011 00:14:24 -0700	[thread overview]
Message-ID: <4D8C40D0.80109@pbjtriplett.org> (raw)
In-Reply-To: <20110325020954.GC4535@khazad-dum.debian.net>

On 3/24/2011 7:09 PM, Henrique de Moraes Holschuh wrote:
> As per the Intel SDM vol 3A, microcode revisions are signed 32-bit
> numbers.  The code was handling them as unsigned int in some places and as
> an int in other places.
> 
> As per the clarification posted by Burt Triplett from the Intel BITS
> project, negative microcode revisions are used internally at Intel and
> should always get loaded.  Also, they should not be overriden unless we
> can somehow differentiate "automated" loading from "forced" loading (which
> we cannot at this time).  Burt says the SDM will be updated with this
> information eventually.
> 
> The code should:
> 
> 1. Ignore attempts to load a zero-revision microcode (that value is
> reserved for the CPU to signal that it is running with the factory
> microcode, and must not be present in a normal microcode update);
> 
> 2. Always load negative revision microcodes, to help Intel's engineers;
> 
> 3. Avoid upgrading from a BIOS-loaded negative revision microcode to
> a normal microcode, to not get in the way of Intel's engineers.
> 
> 4. Upgrade from revision 0 (no updates loaded in CPU) to any revision.
> 
> It was already doing some of that, but I don't feel like trying to track
> down exactly how the old code with its mix of signed/unsigned handling of
> revisions would behave in each of the above cases.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> LKML-Reference: <4D87E2CD.6020306@pbjtriplett.org>
> Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Burt Triplett <burt@pbjtriplett.org>

Reviewed-by: Burt Triplett <burt@pbjtriplett.org>

Thanks,
Burt Triplett

      reply	other threads:[~2011-03-25  7:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24  5:36 [announce] Intel BIOS Implementation Test Suite (BITS) Burt Triplett
2011-03-12  2:30 ` BITS handling of CPU microcode updates Henrique de Moraes Holschuh
2011-03-21 23:44   ` Burt Triplett
2011-03-24  0:14     ` Henrique de Moraes Holschuh
2011-03-24 20:53       ` Burt Triplett
2011-03-25  0:57         ` Henrique de Moraes Holschuh
2011-03-24 21:46       ` Andi Kleen
2011-03-25  7:05         ` Burt Triplett
2011-03-25  2:09       ` x86/microcode: intel: correctly handle negative revisions Henrique de Moraes Holschuh
2011-03-25  7:14         ` Burt Triplett [this message]

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=4D8C40D0.80109@pbjtriplett.org \
    --to=burt@pbjtriplett.org \
    --cc=hmh@hmh.eng.br \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tigran@aivazian.fsnet.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.