OSDev.org

I've got a question about SMM.

Has anyone of you ever tried to figure out what exactly System Management Mode routines do on your PCs? Just for curiosity..

Once, I was told (on this forum) that SMM can manage my USB mouse events, for example. Now I'm trying to understand how it works but it is very hardware-specific (=hard) - manuals do come in handy So far I've managed to make a dump of first MB of ram - including SMM code, though I'm not sure if it's the only place it resides.. I know it does some calls to BIOS but the code in SMRAM itself is quite short.. Looks like a hard task to understand how it works only by examining the code. Or maybe anyone of you took a closer look to SMM? If so, please share your findings here.


p.s. I can provide a memory dump from my PC (965P Intel - ICH8, Core2Duo 4300) if anyone has A LOT of free time and would like to analyze SMM in it

see wikipedia: SMM

SMM is the official name for "unreal mode" with some more extended functionality... 386 CPUs had a hardware bug ( soon turned out to be a hardware feature ) that basically if you return to real mode without resetting segment registers to 64K, 386 continues to have older limit for the segment register and you can access upto 4GB in real mode. SMM mode is something like that, you have real mode, but over 1MB area.

SMM mode was previously used for APM ( first by 386SL CPU family, Advanced Power Management ) and BIOS's low level device, mainboard handling. If you push the power button, on older systems, SMI ( system management interrupt ) is generated and bios handles it to cut the power off in a controlled fashion. OR may be enter sleep mode and disable some devices connected to PC, and re-enable them on wake-up. OR motherboard chipset can generate the SMI to itself ( BIOS ) so that bios code handles some other lowlevel handling of the motherboard.

Upto now, it was OK, since normally you dont receive SMI. only during shutdown. and probably because PC is shutting down, you don't return from it. But lately, board manufacturers started using SMI for simulating/virtualizing non-existent hardware. How does it do it? well, if cpu tries to access let's say to PS/2 mouse ports, the chipset traps the cpu and sends an smi. the smi handler changes the SMI dump area ( reserved sections ) and simulates a return value from this port. This way you can simulate a PS/2 mouse if you have let's say another USB mouse/keyboard.

CPU enters SMM only by SMI ( system management interrupt ) which you can generate by manipulating chipset registers or by using Local APIC Interrupt Command Register with DMODE ( delivery mode ) set to SMI ( 010 ) When SMI occurs, world stops and BIOS starts to execute. OS have almost no way of masking SMI. and it won't even notice it when it does occur. ( well not always ) Microsoft doesn't want people to use SMI for hardware virtualizing because some boards come with buggy BIOS that corrupt PCI, ACPI or USB state to handle USBtoPS/2 mouse, which confuses windows and worst case, bring it down. But well who listens to what microsoft says

Basically, I believe, SMM is reserved by Intel for board manufacturers for hardware debugging purposes in mind. Some hardware hackers know that you can generate really funny CPU states, like VM86 with 4GB segment limits, segment limits that are not generateable by standard 20bit plus page/byte bit segment descriptor like limit 0x12345678, 32bit port addresses, reversing port and memory accesses by manipulating reserved area and RSM instruction. but other than that SMM has no other practical use for OS developpers.

Cemre wrote:SMM is the official name for "unreal mode"

No it isn't.

Tyler wrote:

Cemre wrote:SMM is the official name for "unreal mode"

No it isn't.

You might wanna google that a little bit it is

When people found out about unreal mode, they thought intel put it there accidentally, but it was only an implementation side effect of SMM mode SMM mode and unreal mode did originate from each other.

Dr. Dobbs articles have good explanation of this.
http://www.x86.org/ddj/ddj.htm

The Secrets of System Management Mode
http://www.rcollins.org/ddj/Mar97/Mar97.html

The Segment Descriptor Cache
http://www.x86.org/ddj/aug98/aug98.htm

Intel's System Management Mode
http://www.ddj.com/184410120

SMM mode was first introduced when intel decided to start the CPU at address FFFFFFF0 on real mode. that is where bios is located. It wasn't named SMM at the time. CPU at power up executes a hardcoded RSM instruction, which loads the cpu internal registers just like a LOADALL instruction would. and places the cpu to FFFFFFF0 with real mode.

you might also want to check that

http://www.x86.org/articles/loadall/tspec_a3_doc.htm

Cemre wrote:

Tyler wrote:

Cemre wrote:SMM is the official name for "unreal mode"

No it isn't.

You might wanna google that a little bit it is

No thanks, my statement was prefectly correct. I don't disagree with any other bit of your post. SMM is not the official name for "unreal mode".

No it isn't.

No thanks, my statement was prefectly correct. I don't disagree with any other bit of your post. SMM is not the official name for "unreal mode".

sounds like arrogance to me. Maybe explain your side of the argument a little better to enlighten those reading along.

Intel intentionally didn't implement resetting cpu segment register limits back to 64K upon entring real mode, just to make SMM possible and also to make BIOS able to run at 0xFFFFFFF0 possible at system boot-up.

As I said, What Intel actually had in mind was SMM and BIOS... and unreal mode was just a side-effect of this non-limit-resetting.

What intel planned as SMM and "BIOS at 0xFFFFFFF0 at startup" turned out to be unreal mode for normal users.

That is why original SMM is the official name for unreal mode
unreal mode was the implementation side-effect of SMM ( 386SL ).

if intel didn't make unreal mode possible, it also wouldn't be possible to locate BIOS at 0xFFFFFFF0.

01000101 wrote:

No it isn't.

No thanks, my statement was prefectly correct. I don't disagree with any other bit of your post. SMM is not the official name for "unreal mode".

sounds like arrogance to me. Maybe explain your side of the argument a little better to enlighten those reading along.

Nope, i'm sorry if it seems that way, but what he said was simply wrong... there is nothing for me to explain.

Cemre1 wrote:That is why original SMM is the official name for unreal mode

Nope

Cemre wrote:unreal mode was the implementation side-effect of SMM.

Yep... very different to making people think Unreal mode, which they can set up from there OS is the same as SMM, an unrelated mode they have no access to.

Yep... very different to making people think Unreal mode, which they can set up from there OS is the same as SMM, an unrelated mode they have no access to.

SMM is not unrelated to unreal mode...
When Intel introduced SMM to public, actually, when they named the already existing feature as SMM, they were actually introducing something which the hardware was already capable of doing.

Anyway, I don't think bringing this any further has any point...

Dude, the very arguments you gave claim the opposite of what you say:

Unreal mode is created when a real-mode segment has a four-GB segment limit. Unreal mode can be created without any hardware debuggers or SMM programming with a simple assembly-language program.

In other words, unreal mode is independent of SSM. Therefore unreal mode can't be the same as SSM. I really suggest you read your sources again.

Combuster wrote:Dude, the very arguments you gave claim the opposite of what you say:

Unreal mode is created when a real-mode segment has a four-GB segment limit. Unreal mode can be created without any hardware debuggers or SMM programming with a simple assembly-language program.

In other words, unreal mode is independent of SSM. Therefore unreal mode can't be the same as SSM. I really suggest you read your sources again.

How does the above sentence have anything to say about their independence? I really think you should increase your understanding of documents when you read them... The fact that you can create non-64KB limit real mode without entering SMM doesn't justify SMM and unreal mode are independent. When you enter SMM, the CPU infact creates an unreal mode... When you have SMM, you have real mode and 4GB limit in segment descriptor cache... When you have unreal mode, you again have real mode with non-64KB segment limit... do they seem independent to you?

Unreal mode is created when a real-mode segment has a four-GB segment limit.

SMM also is a real mode with 4GB segment limit...

You are hereby found guilty of being an ignorance troll. The sentence is that you are banished to the the 4 square metres under the bridge.

Combuster wrote:You are hereby found guilty of being an ignorance troll. The sentence is that you are banished to the the 4 square metres under the bridge.

blah blah blah... That is the thing which someone who has nothing to say as a response would say...

If you are gonna reject the obvious, I have nothing further to say...

If you have any claim... prove it as i did.

I can see there's some interesting background (a history? ) about SMM...
It is not really important for me whether SMM is related to unreal mode or not. Although it they both have "some things" in common, I think SMM is much more powerful - as it is closely tied with hardware. Cemre said about its 'transparency' to the software so I'm wondering how one can detect that SMI interrupt occured (without checking MoBo registers). Maybe RDTSC instruction (with 'normal' interrupts disabled):

1. check ticks with RDTSC
2. execute some code which usually takes, say 2000 cycles
3. check ticks with RDTSC
4. time=[3.] - [1.]

If we detected that time=18000 cycles (for example), would that indicate SMI as a cause (or maybe NMI?). Just curious...

To add something to discussion - SMM is officially mentioned and described in Intel manuals, is unreal mode as well? I think unreal mode is unofficial.....