On Sun, Mar 04, 2018 at 03:01:48PM +0100, Pavel Machek wrote:
> > Not "might be needed" - "X86_BUG_AMD_APIC_C1E will be set if platform is
> > affected".
>
> That's not what Thomas was explaining to me.
It is in the comment he pasted:
* Check whether the machine is affected by erratum 400. This is
* used to select the proper idle routine and to enable the check
* whether the machine is affected in arch_post_acpi_init(), which
* sets the X86_BUG_AMD_APIC_C1E bug depending on the MSR check.
> So.. what's magical about it, why do we need two bits, and why is that
> not explained in the header file?
Lemme enable line numbers so that you can find it:
arch/x86/include/asm/cpufeatures.h:
19 /*
20 * Note: If the comment begins with a quoted string, that string is used
21 * in /proc/cpuinfo instead of the macro name. If the string is "",
22 * this feature bit is not displayed in /proc/cpuinfo at all.
> Please go through the email thread,
No, you read Thomas' mail again.
> I'm trying to understand what is going on here,
Nothing's going on, it works as designed.
X86_BUG_AMD_E400 marks all CPUs which could be affected by erratum 400
and X86_BUG_AMD_APIC_C1E is the bit we set when we detect that the CPU
is *actually* affected because we need to do the detection late, after
ACPI has been initialized.
A CPU might be affected by the erratum - bit X86_BUG_AMD_E400 - but if
the BIOS doesn't enter C1E, then the erratum doesn't come to manifest
itself, i.e., we don't set X86_BUG_AMD_APIC_C1E.
If it is still not clear, read the erratum 400 description in the
revision guide.
The code works perfectly fine.
Unless you're experiencing a problem with it. Then I'm all ears.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
