| |||||||||||||
HWPOISONHWPOISONPosted Aug 31, 2009 23:40 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246)In reply to: HWPOISON by dlang Parent article: HWPOISON
I'll quote Andi Kleen's post (that I linked above) since I think it's abundantly clear: Newer Intel CPUs support a new class of machine checks called recoverable action optional. Action Optional means that the CPU detected some form of corruption in the background and tells the OS about using a machine check exception. The OS can then take appropiate action, like killing the process with the corrupted data or logging the event properly to disk. Read that again: Background scrubbing gives a machine check. The machine check is action optional and it can do just as you suggest. It's still a machine check.
(Log in to post comments)
HWPOISON Posted Sep 1, 2009 17:59 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
as I understand it, HWPOISON changes this.
instead of the background scrub triggering a machine check at that point in time it instead just marks the memory as corrupt (poisoned). the poisoned flag gets cleared if the memory is written to.
if nothing ever tries to read the poisoned memory a machine check happens at that point in time.
HWPOISON Posted Sep 1, 2009 20:24 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] That's not how I read this. See section 15.6, "Recovery of Uncorrected Recoverable Errors" and especially 15.6.3, "UCR Error Classification". The first two error types are the "an error was detected, but the CPU hasn't consumed the errant data yet" error types. If you want to pick nits, the first one (UCNA) is not reported as a Machine Check Exception; rather it is reported as a Corrected Machine Check Error Interrupt (described in Section 15.5). My bad for being sloppy; it is a Machine Check Error, but it isn't a Machine Check Exception. The second recoverable error type (SRAO) is a Machine Check Exception, however. In any case, both are machine checks. Now flip with me to page 15-34 and look at what SRAO errors are architecturally defined, there in section 15.9.3.1: The following two SRAO errors are architecturally defined. So there we have it. Recoverable, Action Optional Machine Checks due to scrubbing. Can it be any clearer? In case you think this feature is old and was supplanted by something more recent, I urge you to flip back to 15-23 and read along here at the intro to Section 15.6: Recovery of uncorrected recoverable machine check errors is an enhancement in machine-check architecture. The first processor that supports this feature is 45nm Intel 64 processor with CPUID signature DisplayFamily_DisplayModel encoding of 06H_2EH. This allow system soft- ware to perform recovery action on certain class of uncorrected errors and continue If I'm not mistaken, that's the processor family this article was referring to. (This document is dated June 2009, so it's not like it's anceint.) Do you have different documentation that suggests otherwise?
HWPOISON Posted Sep 1, 2009 21:28 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
ok, I think the question comes down to this
is HWPOISON a hardware level feature or a OS level feature?
if it's a hardware level feature (which is what I understood from the original article) then it wouldn't necessarily cause a machine check error ever.
if this is instead a difference in how the OS responds to a memory error I just completely misunderstood what's happening.
HWPOISON Posted Sep 1, 2009 23:59 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
The overall "HWPOISON feature" is both a hardware feature and a software feature. There is a hardware component (the newly improved Machine Check Architecture in the CPU), and then there's the OS handler that makes use of it.
A machine check error (whether delivered as an exception or an interrupt--the new MCA does both depending on the error type) is a message from the hardware to the software. In the most recent Intel architectures, they support a notion of "recoverable machine check," wherein the hardware tells the OS that no CPU state was corrupted when it noticed the problem. If you look at that PDF I linked, there are a number of status bits (including AR--Action Required) that indicate the severity of the error. There's a separate table in Intel's PDF that suggests the possible OS responses to a particular error.
Once the hardware delivers the message to the OS (via a machine check), the OS is then free to deal with the machine check however it pleases. For "Action Optional" machine checks that can happen asynchronously to program execution (such as due to scrubbing), the OS can queue up a handler to go deal with the affected page, either by poisoning it or unmapping it or what-have-you. That's the stuff Andi Kleen and co.'s patch does.
HWPOISON Posted Sep 1, 2009 20:26 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] I guess what you're missing is who marks the memory as poisoned. The CPU sends a machine check to the OS. The OS marks the memory as poisoned, or otherwise discards the contents of the page if it was clean. The HWPOISON patch provides the OS handler and hooks to poison the page (or do whatever needs doing) when the machine check arrives.
HWPOISON Posted Sep 1, 2009 21:31 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
Ok, I was reading this as something new being implemented at the hardware layer by Intel
HWPOISON Posted Sep 1, 2009 23:47 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
It's both. The hardware now supports a concept of recoverable machine check, and the software uses it.
|
|||||||||||||