[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161024093510.od57fbvn5rsgxcua@pd.tnic>
Date: Mon, 24 Oct 2016 11:35:10 +0200
From: Borislav Petkov <bp@...en8.de>
To: sonofagun@...nmailbox.org
Cc: linux-kernel@...r.kernel.org, Nikos Barkas <levelwol@...il.com>
Subject: Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix
On Mon, Oct 24, 2016 at 02:38:06PM +0300, sonofagun@...nmailbox.org wrote:
> The patch is not equivalent to the original. As a result it behaves
> differently. To be specific, using dmesg I get the expected value from the
> affected MSR with the original patch. With the latest patch, patching of the
> MSR occurs after dmesg prints the MSR information. That is why I thought it
> did nothing.
Gah, that "show_msr" is crap - it gets issued too early and we can -
and we do - set MSRs later too. Oh and it prints only the BSP. I should
probably rip it out - there's msr-tools for that which is much better.
> rdmsr --all 0xc0011021 returns the expected results on all CPUs with both
> patches. I have the impression that the system boots slower because the fix
> is applied later compared to the original patch.
Could be - setting those bits 3 in 14 in that MSR is probably disabling
some hw features which may impact performance.
> Could you please use perf and tell me what values do you get at perf
> branch-misses right after boot on your ON-B0 box? Launching firefox with
> only one tab gives you similar numbers?
Sure, give me the exact command you're executing so that I can do it here.
> If you need anything more, feel free to ask.
Out of pure interest: do you remember how exactly you did reproduce this
issue?
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists