Programming and Web Development Forums - linux - Hardware compatibility with the Linux operating system.
Hello, Aragorn a rit : Like on any other platform, I guess. ECC is a hardware operation performed by the memory controller. Only exceptions caused by uncorrectable errors, which are supposed to be rare, may be handled by software.
Sorry, "memory mappings" was misleading; SMM sets up an identity mapping (virtual=physical) without any page table. My point was that this 'flat' mode is explicitly set up, regardless of what mapping was in use before. Well, there are two definitions of "corrected" that could apply here. When the CPU wants to read some memory location, and if the ECC algorithm detects an error and can detect which of the bits has a wrong value, the value that is sent to the CPU is the correct one. (1) That value can also be written back into the RAM so that the error won't occur again the next time that location is read. (2) (1) _must_ be done by the memory controller; (2) can be done either by the memory controller or by the CPU. Yes. Code running in SMM must be able to access all registers, all memory, and all hardware; and SMM code is always hardware dependent, so no backwards compatibility is needed. Best regards, Clemens
On Thursday 28 January 2010 09:16 in comp.os.linux.hardware, somebody identifying as Clemens Ladisch wrote... And what about the scrubbing of the CPU cache? The cache sits in between the CPU and the memory controller, so this cannot be "cleaned" by the memory controller, can it? Would this then be "cleaned" by the CPU, and if so, by the operating system or by SMM code? -- *Aragorn* (registered GNU/Linux user #223157)
Aragorn a rit : The CPU or any other bus master, such as any DMA-capable adapter : graphics, mass storage, network... Correct. By the CPU's integrated cache controller, at least for (1).
On Thursday 28 January 2010 15:14 in comp.os.linux.hardware, somebody identifying as Pascal Hambourg wrote... Okay, thanks for clearing that up. ;-) -- *Aragorn* (registered GNU/Linux user #223157)
Greetings, fellow penguinistas, Okay, this is one of those rare occasions where I'm actually starting a thread myself, hoping to find some answers. ;-) I have been doing some reading lately on the Systems Management Mode (SMM) introduced to the x86 architecture through the release of the Intel 80386SL processor. From what I've gleaned via Google searches, Systems Management Mode began its life as an undocumented feature - or bug? - of the i386 architecture commonly called "unreal mode", "big real mode" or "flat real mode". Unlike what its name says, it's not really a separate mode of operation like real mode, protected mode or virtual 8086 mode. "Unreal mode" is invoked by entering a fully set up protected mode and then clearing the protection bit on the processor, so that it would drop back to real mode but with the pagetables and the global and local descriptor tables all still in place, without clearing/overwriting them. This allows the processor to access the full 32-bit address range of 4 GB from within (what is essentially) real mode. Hence the description "unreal mode", "big real mode" or "flat real mode". Originally, this undocumented "unreal mode" was put to use by a number of DOS games that required more than the 1 MB address space offered by normal real mode, but eventually this method for accessing more RAM was largely supplanted by DOS extenders such as DPMI. That's when Intel decided to officially introduce the Systems Management Mode on the i386SL, by making use of "unreal mode" to run high-privileged BIOS code in ring 0, among other things for power management, e.g. turning on fans. Another use of SMM, as I understand it, is to emulate a PS/2 keyboard controller for USB keyboards (and mice) when an operating system is used that does not support USB - i.e. the so-called "enable legacy USB devices" setting in the BIOS set-up program - which is useful when the machine only has a USB keyboard (or mouse) attached, so that one can access the BIOS set-up program or make selections in a bootloader. (As I understand it, Linux emulates a PS/2 keyboard controller for USB keyboards and mice via its "HID" ("Human Input Devices") drivers, so SMM would not be needed there.) Now, according to one of the sources I've found via Google, x86 machines with ECC would be making use of Systems Management Mode (and thus "unreal mode") to correct errors in memory, but other than simply mentioning this, the webpage did not elaborate on this subject, and I couldn't find any other sources corroborating this. In a way, it would appear logical to me if ECC were indeed to use SMM, given that SMM is considered the highest privileged mode of operation on x86 - so highly privileged that even execution of the operating system is temporarily halted without that the operating system even knows (which has already been exploited by "proof of concept" rootkits) - but on the other hand it doesn't really make sense, and here's why: (1) There are many RISC-based machines with ECC, and RISC architectures do not have any "real mode" (and thus also no "unreal mode"). (2) SMM requires "unreal mode", and "unreal mode" can only be initiated by entering 32-bit protected mode first and then clearing the protection bit without clearing the pagetables and descriptor tables, but because long mode on x86-64 differs in operation from 32-bit protected mode there is no 64-bit equivalent for "unreal mode". In other words, SMM would never be able to access more than 4 GB of RAM. I'm not sure on whether PAE pagetables could be used, but even if that were the case, the address range would then still be limited to 64 GB only, and so this would make ECC - if it does indeed use SMM and thus "unreal mode" - inadequate on x86-64 systems with more than 64 GB installed. (3) ECC checks are performed at fairly high frequency, and entering SMM (and thus "unreal mode") with the prospect of being able to return to normal protected mode requires that the processor saves all of its registers first before clearing the protection bit, which is a very expensive operation in terms of clock cycles. As such, systems with ECC operating at its highest frequency would suffer an incredible performance loss during normal execution of the operating system and userspace processes. That doesn't seem quite logical on high performance/high throughput servers and workstations, and indeed, such systems don't appear to be slowing down too much with ECC enabled. So, can anyone here enlighten me on how the high-privileged ECC routines are executed on x86-64? Is this something that would be executed by the operating system itself while in long mode, or how does this work? Thanks in advance, -- *Aragorn* (registered GNU/Linux user #223157)
Users browsing this forum: No registered users and 64 guest