linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, H Peter Anvin <hpa@zytor.com>
Subject: Re: [PATCH 2/8] x86, microcode, intel: don't update each HT core twice
Date: Mon, 20 Oct 2014 16:24:27 -0200	[thread overview]
Message-ID: <20141020182427.GB19306@khazad-dum.debian.net> (raw)
In-Reply-To: <20141020133252.GC3524@pd.tnic>

On Mon, 20 Oct 2014, Borislav Petkov wrote:
> On Mon, Sep 08, 2014 at 02:37:48PM -0300, Henrique de Moraes Holschuh wrote:
> > -static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
> > +static void __collect_cpu_info(int cpu_num, struct cpu_signature *csig)
> >  {
> >  	struct cpuinfo_x86 *c = &cpu_data(cpu_num);
> >  	unsigned int val[2];
> > @@ -102,7 +102,19 @@ static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
> >  		csig->pf = 1 << ((val[1] >> 18) & 7);
> >  	}
> >  
> > -	csig->rev = c->microcode;
> > +	/* get the current microcode revision from MSR 0x8B */
> > +	wrmsr(MSR_IA32_UCODE_REV, 0, 0);
> > +	sync_core();
> > +	rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
> > +
> > +	csig->rev = val[1];
> > +	c->microcode = val[1];  /* re-sync */
> > +}
> > +
> > +static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
> > +{
> > +	__collect_cpu_info(cpu_num, csig);
> > +
> >  	pr_info("CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
> >  		cpu_num, csig->sig, csig->pf, csig->rev);
> 
> We probably should downgrade this to pr_debug and use collect_cpu_info()
> everywhere instead of having a __ version.

Over time, grepping for that information on reports and logs all over the
net has helped me a great deal.  In fact, it is in my backlog to add it to
the early microcode driver as well.

I really miss the full microcode ID information in /proc/cpuinfo, in fact.

If you want, I can modify the logging it in a future patch so that we print
it only once when all cores have the same sig, pf and revision (which should
cover 95% of the systems out there).

> > -	/* write microcode via MSR 0x79 */
> > +	/* write microcode via MSR 0x79. THIS IS VERY EXPENSIVE */
> 
> No need for screaming here - we know MSR accesses are expensive. This
> comment is totally useless here so drop it altogether.

MSR 79H writes are on a class of their own as far as "expensive" goes... On
a modern i3/i5/i7, it will take approximately one million cycles to complete
(the larger the microcode update, the longer it takes).

I don't think people usually associate MSR write with "takes one million
cycles to complete"...

That said, I will remove the comment.

> >  	wrmsr(MSR_IA32_UCODE_WRITE,
> > -	      (unsigned long) mc_intel->bits,
> > -	      (unsigned long) mc_intel->bits >> 16 >> 16);
> > -	wrmsr(MSR_IA32_UCODE_REV, 0, 0);
> > -
> > -	/* As documented in the SDM: Do a CPUID 1 here */
> > -	sync_core();
> > +		lower_32_bits((unsigned long) mc_intel->bits),
> > +		upper_32_bits((unsigned long) mc_intel->bits));
> 
> wrmsrl() takes u64 directly - no need for the splitting.

This is old code, I guess it predates wrmsrl()...

Should I replace the old split version with wrmsrl() in this patch, or as a
separate patch?

-- 
  "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

  reply	other threads:[~2014-10-20 18:24 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 17:37 [PATCH 0/8] x86, microcode, intel: fixes and enhancements Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 1/8] x86, microcode, intel: forbid some incorrect metadata Henrique de Moraes Holschuh
2014-10-05 17:34   ` Borislav Petkov
2014-10-05 19:37     ` Henrique de Moraes Holschuh
2014-10-05 21:13       ` Borislav Petkov
2014-10-05 21:49         ` Henrique de Moraes Holschuh
2014-10-06  5:15           ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 2/8] x86, microcode, intel: don't update each HT core twice Henrique de Moraes Holschuh
2014-10-20 13:32   ` Borislav Petkov
2014-10-20 18:24     ` Henrique de Moraes Holschuh [this message]
2014-10-28 17:31       ` Borislav Petkov
2014-10-31 18:43         ` Henrique de Moraes Holschuh
2014-11-01 11:06           ` Borislav Petkov
2014-11-01 19:20             ` Henrique de Moraes Holschuh
2014-11-04 15:53               ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 3/8] x86, microcode, intel: clarify log messages Henrique de Moraes Holschuh
2014-10-20 13:52   ` Borislav Petkov
2014-10-21 14:13     ` Henrique de Moraes Holschuh
2014-10-29  9:54       ` Borislav Petkov
2014-10-31 20:08         ` Henrique de Moraes Holschuh
2014-11-07 17:37           ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 4/8] x86, microcode, intel: add error logging to early update driver Henrique de Moraes Holschuh
2014-10-20 15:08   ` Borislav Petkov
2014-10-21 14:10     ` Henrique de Moraes Holschuh
2014-10-30 17:41       ` Borislav Petkov
2014-10-30 18:15         ` Joe Perches
2014-10-31 20:10         ` Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 5/8] x86, microcode, intel: don't check extsig entry checksum Henrique de Moraes Holschuh
2014-10-30 20:25   ` Borislav Petkov
2014-10-31 17:14     ` Henrique de Moraes Holschuh
2014-11-07 17:49       ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 6/8] x86, microcode, intel: use cpuid explicitly instead of sync_core Henrique de Moraes Holschuh
2014-11-07 17:56   ` Borislav Petkov
2014-11-07 18:40     ` Henrique de Moraes Holschuh
2014-11-07 19:48       ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 7/8] x86, microcode, intel: guard against misaligned microcode data Henrique de Moraes Holschuh
2014-09-18  0:48   ` Henrique de Moraes Holschuh
2014-11-07 19:59   ` Borislav Petkov
2014-11-07 22:54     ` Henrique de Moraes Holschuh
2014-11-07 23:48       ` Borislav Petkov
2014-11-08 21:57         ` Henrique de Moraes Holschuh
2014-11-11 10:47           ` Borislav Petkov
2014-11-11 16:57             ` Henrique de Moraes Holschuh
2014-11-11 17:13               ` Borislav Petkov
2014-11-11 19:54                 ` Henrique de Moraes Holschuh
2014-11-12 12:31                   ` Borislav Petkov
2014-11-13  0:18                     ` Henrique de Moraes Holschuh
2014-11-13 11:53                       ` Borislav Petkov
2014-11-15 23:10                         ` Henrique de Moraes Holschuh
2014-11-24 17:35                           ` Borislav Petkov
2014-11-25 13:29                             ` Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 8/8] x86, microcode, intel: defend apply_microcode_intel with BUG_ON Henrique de Moraes Holschuh
2014-11-07 20:05   ` Borislav Petkov
2014-11-07 22:56     ` Henrique de Moraes Holschuh
2014-11-07 23:48       ` 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=20141020182427.GB19306@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).