lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f1a065b0801041333x579d0a8fs9c5535f95dd56015@mail.gmail.com>
Date:	Fri, 4 Jan 2008 13:33:33 -0800
From:	"Russell Leidich" <rml@...gle.com>
To:	"Andi Kleen" <andi@...stfloor.org>,
	"Torsten Kaiser" <just.for.lkml@...glemail.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>, valdis.kletnieks@...edu,
	thockin@...gle.com
Subject: Re: [PATCH] AMD Thermal Interrupt Support

Here's a new version of the patch.  Since I didn't explain its purpose
very well in my previous submission, I'll do so here:

This patch adds thermal machine check event (MCE) support to AMD
Barcelona (and probably later, if new PCI IDs are added to
k8_northbridges[]), styled after the same in the Intel code.  The
initialization consists of 3 parts: (1) northbridge, which enables the
delivery of the interrupt to the local APIC, (2) APIC, which enables
delivery to X86, and (3) hotplug support in threshold_cpu_callback(),
which accomplishes #2 for CPUs which (re)enter the OS later.

Whenever the temperature reaches the throttling threshold programmed
into a northbridge register (by the BIOS -- my code doesn't change
this value), a thermal interrupt is delivered.  The interrupt is
delivered to the vector specified in the thermal APIC register at
(APIC_BASE + 0x330), which is identical to Intel.  Because the vector
register is the same between both architectures, and because I don't
know which brand of CPU is present until runtime (if either),
thermal_interrupt in entry_64.S will branch to smp_thermal_interrupt
in mce_thermal.c.  In turn, smp_thermal_interrupt will branch to the
CPU-specific code for handling the interrupt.  (Apart from the common
vector location, AMD and Intel use radically different architectures
for the purpose of reporting throttling events.)  At that point, an
MCE is logged if and only if the temperature has made a low-to-high
transition.  Rate limiting is employed so as not to spam the log.

New with this patch: I added some comments, as Andi suggested.  I also
restored a redundant check for (cpu < NR_CPUS) which happened to be in
mce_amd_64.c, and I originally removed; I restored it because it was
deemed unrelated to my thermal throttling enhancement.

As to the question of Athlon RevG, it turns out that it has the same
thermal erratum as RevF.  Therefore the fact that this code only works
with Barcelona and up is not a defficiency.

There are 2 pending issues, to which I have received insufficient feedback:

1. Andi would like to eliminate the trampoline in mce_thermal.c, but
no one has responded to my proposed disgusting hack on entry_64.S in
order to do so.

2. Ingo pointed out that a given config file did not build.  But when
I tried to use it, I got all kinds of questions about the required
states of various build flags.  I accepted all the defaults, and the
build completed normally.  His error message suggests to me that
somehow he's not including include/asm-x86/mce.h in the build, but I'm
at a loss as to why.  So I reverted my changes to this file, and
created mce_thermal.h instead, for tighter control.

-- 
Russell Leidich

View attachment "patch.txt" of type "text/plain" (11791 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ