Regarding SMM mode

NTDEV
1

HI All ,

I need to write an driver which makes use of processor SMM mode and try
to accomplish some functionality implemented by BIOS , I am running on
multiprocessor and Windows 2003 , which processor will be entered in SMM
mode and what will happen to the other processor running ? Moreover I
need to make sure that routine which generate the SMI, should be running
only on single processor!! since I am filling some registers to before
generating SMI , Current behavior is system is freezing for ever, I am
not sure what is the reason ,

Has somebody has tried writing an SMI driver on Windows environment?
Can somebody tell me, what all thing a driver writer should take care
while doing this?

Thanks in Advance.

Thanks and Regards

~Neeraj

2

“Ladkani, Neeraj” wrote in message news:xxxxx@ntdev…
>HI All ,
>
>I need to write an driver which makes use of processor SMM mode and try
>to accomplish some functionality implemented by BIOS , I am running on
>multiprocessor and Windows 2003 , which processor will be entered in SMM
>mode and what will happen to the other processor running ? Moreover I
>need to make sure that routine which generate the SMI, should be running
>only on single processor!! since I am filling some registers to before
>generating SMI , Current behavior is system is freezing for ever, I am
>not sure what is the reason ,
>
>
>Has somebody has tried writing an SMI driver on Windows environment?
>Can somebody tell me, what all thing a driver writer should take care
>while doing this?

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

3

NEERAJ:

Pavel is quite correct; off the top of my head, this is probably the
most unsupported aspect of Windows internals that I can think of. All
that being said, how are you getting in to SMM presently? The
essentially terminal issue with SMM is that, unless you have something
like and Arium ECM-50 or some other hardware debugger with SMI support
(which I don’t think is out there), this problem is guaranteed to be
100% non-debuggable, because, as Pavel pointed out, WinDbg, like any
other piece of software running on the computer can not see the memory
used by SMM (except for the handler itself). There is no way that I’m
aware of to do this without some hardware debugging support, which is no
at all cheap. I might be able to help you have this sort of support
already or can get it, but otherwise, there is really nothing that can
be done without it.

mm

>> xxxxx@writeme.com 2006-12-14 12:35 >>>
“Ladkani, Neeraj” wrote in message
news:xxxxx@ntdev…
>HI All ,
>
>I need to write an driver which makes use of processor SMM mode and
try
>to accomplish some functionality implemented by BIOS , I am running
on
>multiprocessor and Windows 2003 , which processor will be entered in
SMM
>mode and what will happen to the other processor running ? Moreover
I
>need to make sure that routine which generate the SMI, should be
running
>only on single processor!! since I am filling some registers to
before
>generating SMI , Current behavior is system is freezing for ever, I
am
>not sure what is the reason ,
>
>
>Has somebody has tried writing an SMI driver on Windows environment?
>Can somebody tell me, what all thing a driver writer should take care
>while doing this?

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

I agree to the Martin and Pavel ,

But I was not aware if I can use ACPI from win 2k3 , I assumed that
could be done only from Vista ,

Current I am fetching SMI port from ACPI tables, and making use of that
…

Can you tell me, is it possible to use ACPI to use for SMI?

Thanks and Regards
~Neeraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, December 14, 2006 11:37 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Regarding SMM mode

NEERAJ:

Pavel is quite correct; off the top of my head, this is probably the
most unsupported aspect of Windows internals that I can think of. All
that being said, how are you getting in to SMM presently? The
essentially terminal issue with SMM is that, unless you have something
like and Arium ECM-50 or some other hardware debugger with SMI support
(which I don’t think is out there), this problem is guaranteed to be
100% non-debuggable, because, as Pavel pointed out, WinDbg, like any
other piece of software running on the computer can not see the memory
used by SMM (except for the handler itself). There is no way that I’m
aware of to do this without some hardware debugging support, which is no
at all cheap. I might be able to help you have this sort of support
already or can get it, but otherwise, there is really nothing that can
be done without it.

mm

>> xxxxx@writeme.com 2006-12-14 12:35 >>>
“Ladkani, Neeraj” wrote in message
news:xxxxx@ntdev…
>HI All ,
>
>I need to write an driver which makes use of processor SMM mode and
try
>to accomplish some functionality implemented by BIOS , I am running
on
>multiprocessor and Windows 2003 , which processor will be entered in
SMM
>mode and what will happen to the other processor running ? Moreover
I
>need to make sure that routine which generate the SMI, should be
running
>only on single processor!! since I am filling some registers to
before
>generating SMI , Current behavior is system is freezing for ever, I
am
>not sure what is the reason ,
>
>
>Has somebody has tried writing an SMI driver on Windows environment?
>Can somebody tell me, what all thing a driver writer should take care
>while doing this?

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

This is partially true, but there is more SMM activity occurring at
runtime that you might expect, and there are some legitimate reasons why
a driver would need to trigger a function that is implemented in SMM. I
spoke with Neeraj offline and this is a legitimate case…

But as people have pointed out the OS is totally unaware of SMM, which
leads to the question: If you are going to trigger SMM code from the OS
what is the state that the OS/Driver should be in when this happens? We
have seen issues where SMM was happening during PCI transactions which
destabilized the systems, I assume there are other timing-sensitive
operations at both the hardware and OS level that should be temporarily
suspended before the SMM function is triggered.

Keep in mind that Neeraj’s driver is for a “maintenance function” so
impacts to system performance are not an issue, it would probably run a
couple of times per year for a few minutes.

-Zach

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272926-
xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Thursday, December 14, 2006 9:35 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Regarding SMM mode

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

6

Can we make use of a BIOS routine (SMI routine) from ACPI tables? I
heard its possible from VISTA ?

Does anybody know about it ?

Thanks and Regards
~Neeraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladkani, Neeraj
Sent: Friday, December 15, 2006 12:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Regarding SMM mode

I agree to the Martin and Pavel ,

But I was not aware if I can use ACPI from win 2k3 , I assumed that
could be done only from Vista ,

Current I am fetching SMI port from ACPI tables, and making use of that
…

Can you tell me, is it possible to use ACPI to use for SMI?

Thanks and Regards
~Neeraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, December 14, 2006 11:37 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Regarding SMM mode

NEERAJ:

Pavel is quite correct; off the top of my head, this is probably the
most unsupported aspect of Windows internals that I can think of. All
that being said, how are you getting in to SMM presently? The
essentially terminal issue with SMM is that, unless you have something
like and Arium ECM-50 or some other hardware debugger with SMI support
(which I don’t think is out there), this problem is guaranteed to be
100% non-debuggable, because, as Pavel pointed out, WinDbg, like any
other piece of software running on the computer can not see the memory
used by SMM (except for the handler itself). There is no way that I’m
aware of to do this without some hardware debugging support, which is no
at all cheap. I might be able to help you have this sort of support
already or can get it, but otherwise, there is really nothing that can
be done without it.

mm

>> xxxxx@writeme.com 2006-12-14 12:35 >>>
“Ladkani, Neeraj” wrote in message
news:xxxxx@ntdev…
>HI All ,
>
>I need to write an driver which makes use of processor SMM mode and
try
>to accomplish some functionality implemented by BIOS , I am running
on
>multiprocessor and Windows 2003 , which processor will be entered in
SMM
>mode and what will happen to the other processor running ? Moreover
I
>need to make sure that routine which generate the SMI, should be
running
>only on single processor!! since I am filling some registers to
before
>generating SMI , Current behavior is system is freezing for ever, I
am
>not sure what is the reason ,
>
>
>Has somebody has tried writing an SMI driver on Windows environment?
>Can somebody tell me, what all thing a driver writer should take care
>while doing this?

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Sort of. You can cause an SMI to be generated, but there is nothing you
can after that that you will be able to debug without some additional
hardware. Based on what you originally wrote, you’ve got the right
idea, and it sounds like you might actually be entering SMM already.
However, even if you have made it that far, you can see the problem -
totally hung machine. Why is it hung? Who knows, and there is no
reasonably way to figure it out without a working debugger, which has to
be hardware based. Even then, I still don’t see how you’re going to get
any of your code in to SMM, unless you are asking if there is something
in ACPI that will do this for you. I do not know the answer to that,
but I very seriously doubt it. ACPI will get you there, but not with
any cargo.

ACPI definitely exists in XP, assuming that you’re hardware supports
it, and that you use the correct HAL (and I believe there is an
undocumented F key to disable it during boot).

What is it specifically that you would like ACPI to do for you as far
as SMM goes?

mm

>> xxxxx@intel.com 2006-12-14 13:38 >>>
I agree to the Martin and Pavel ,

But I was not aware if I can use ACPI from win 2k3 , I assumed that
could be done only from Vista ,

Current I am fetching SMI port from ACPI tables, and making use of
that
…

Can you tell me, is it possible to use ACPI to use for SMI?

Thanks and Regards
~Neeraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, December 14, 2006 11:37 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Regarding SMM mode

NEERAJ:

Pavel is quite correct; off the top of my head, this is probably the
most unsupported aspect of Windows internals that I can think of.
All
that being said, how are you getting in to SMM presently? The
essentially terminal issue with SMM is that, unless you have something
like and Arium ECM-50 or some other hardware debugger with SMI support
(which I don’t think is out there), this problem is guaranteed to be
100% non-debuggable, because, as Pavel pointed out, WinDbg, like any
other piece of software running on the computer can not see the memory
used by SMM (except for the handler itself). There is no way that I’m
aware of to do this without some hardware debugging support, which is
no
at all cheap. I might be able to help you have this sort of support
already or can get it, but otherwise, there is really nothing that can
be done without it.

mm

>> xxxxx@writeme.com 2006-12-14 12:35 >>>
“Ladkani, Neeraj” wrote in message
news:xxxxx@ntdev…
>HI All ,
>
>I need to write an driver which makes use of processor SMM mode and
try
>to accomplish some functionality implemented by BIOS , I am running
on
>multiprocessor and Windows 2003 , which processor will be entered in
SMM
>mode and what will happen to the other processor running ? Moreover
I
>need to make sure that routine which generate the SMI, should be
running
>only on single processor!! since I am filling some registers to
before
>generating SMI , Current behavior is system is freezing for ever, I
am
>not sure what is the reason ,
>
>
>Has somebody has tried writing an SMI driver on Windows environment?
>Can somebody tell me, what all thing a driver writer should take care
>while doing this?

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

ZACH:

Could you be specific as to what conditions would cause entry in to
SMM? I haven’t seen a great deal of activity, and I’m wondering if I’m
missing something.

mm

>> xxxxx@intel.com 2006-12-14 13:54 >>>

This is partially true, but there is more SMM activity occurring at
runtime that you might expect, and there are some legitimate reasons
why
a driver would need to trigger a function that is implemented in SMM.
I
spoke with Neeraj offline and this is a legitimate case…

But as people have pointed out the OS is totally unaware of SMM, which
leads to the question: If you are going to trigger SMM code from the
OS
what is the state that the OS/Driver should be in when this happens?
We
have seen issues where SMM was happening during PCI transactions which
destabilized the systems, I assume there are other timing-sensitive
operations at both the hardware and OS level that should be
temporarily
suspended before the SMM function is triggered.

Keep in mind that Neeraj’s driver is for a “maintenance function” so
impacts to system performance are not an issue, it would probably run
a
couple of times per year for a few minutes.

-Zach

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272926-
xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Thursday, December 14, 2006 9:35 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Regarding SMM mode

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

SMM can be invoked on a lot of different triggers, and sometimes when
the OS/Driver thinks it is writing to a hardware register that write is
actually getting trapped by SMM and implemented in software… Any
platform feature that appears to the OS as an IO read/write is a likely
candidate, e.g. power management features, firmware updates, etc.

It sounds like you have a hardware debugger? If you aren’t seeing SMM
activity at runtime then it’s possible your target isn’t using this
“technique”.

SMM is like another dimension in the universe where time (as perceived
by the OS) stands still. Of course mere mortals with only the kernel
debugger will not even know this dimension exists! :wink:

-Zach

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272961-
xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, December 14, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Regarding SMM mode

ZACH:

Could you be specific as to what conditions would cause entry in to
SMM? I haven’t seen a great deal of activity, and I’m wondering if I’m
missing something.

mm

10

ZACH:

Thanks for the reply.

I have an ECM-50 connected to an Intel EMT E7520 CBR running
6000-x64-CHK of Vista. Presently, I’m not really looking at SMM
specificially, but, I have in the past, and, as chance would have it, I
set breakpoints (processor) on SMM Entry and Exit. I haven’t seen
anything all day (other than during the early stages of target reset).
I attributed this to my having disabled anything processor and disk
power related (not monitor). Should I still be seeing some activity?
Of the top of your head, is there a particular IO location of the type
you described that you would recommend using to test due to ease of
triggering once the os is fully running? If so, I would greatly
appreciate it, as I haven’t looked at SMM in about a year, when I did it
was almost exclusively focused on the initialization of it during the
early stages of target reset, and there has to be an easier way than the
way I did it.

Mostly just curious.

Thanks,

mm

>> xxxxx@intel.com 2006-12-14 17:27 >>>

SMM can be invoked on a lot of different triggers, and sometimes when
the OS/Driver thinks it is writing to a hardware register that write
is
actually getting trapped by SMM and implemented in software… Any
platform feature that appears to the OS as an IO read/write is a
likely
candidate, e.g. power management features, firmware updates, etc.

It sounds like you have a hardware debugger? If you aren’t seeing SMM
activity at runtime then it’s possible your target isn’t using this
“technique”.

SMM is like another dimension in the universe where time (as perceived
by the OS) stands still. Of course mere mortals with only the kernel
debugger will not even know this dimension exists! :wink:

-Zach

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272961-
xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, December 14, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Regarding SMM mode

ZACH:

Could you be specific as to what conditions would cause entry in to
SMM? I haven’t seen a great deal of activity, and I’m wondering if
I’m
missing something.

mm

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

11

I’ve done it.

Usually, the requirement is that you trigger the SMI while running on
processor 0. I’m not quite sure what you mean when you say that you “should
be running only on a single processor.” That’s not really possible. You
can’t effectively disable a processor once it has been started - at least
not with any expectation that Windows will continue to run.

So get your code running on Processor 0 and try again. If you need to
figure out how to do that, try KeSetSystemAffinityThread and remember call
the corresponding revert function when you’re done. Note that this only has
an effect on code running at PASSIVE_LEVEL. If you need to do this while
running at DISPATCH_LEVEL, then you need to send a DPC to processor 0 and do
the work in that DPC.

If you want to verify that you’re getting the right value from the ACPI
tables for the SMI command port, type !fadt in the debugger. One of the
fields listed is the SMI command port. (It may not surprise you to know
that several drivers Microsoft ships have to do this. I worked on most of
them at one time or another.)

  • Jake Oshins
    Windows Kernel Team

“Ladkani, Neeraj” wrote in message
news:xxxxx@ntdev…
HI All ,
I need to write an driver which makes use of processor SMM mode and try to
accomplish some functionality implemented by BIOS , I am running on
multiprocessor and Windows 2003 , which processor will be entered in SMM
mode and what will happen to the other processor running ? Moreover I need
to make sure that routine which generate the SMI, should be running only on
single processor!! since I am filling some registers to before generating
SMI , Current behavior is system is freezing for ever, I am not sure what is
the reason ,

Has somebody has tried writing an SMI driver on Windows environment? Can
somebody tell me, what all thing a driver writer should take care while
doing this?

Thanks in Advance.

Thanks and Regards
~Neeraj

12

By the way, if your machine has an AGP slot, it’s pretty easy to reprogram
the GART to be able to look at the SMM region. This makes it much easier to
figure out what might happen when you trigger an SMI.

If there is no AGP hardware on your machine, there are usually other holes
you can poke your nose through. Go read the chipset manual.

  • Jake Oshins
    Windows Kernel Team

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> NEERAJ:
>
> Pavel is quite correct; off the top of my head, this is probably the
> most unsupported aspect of Windows internals that I can think of. All
> that being said, how are you getting in to SMM presently? The
> essentially terminal issue with SMM is that, unless you have something
> like and Arium ECM-50 or some other hardware debugger with SMI support
> (which I don’t think is out there), this problem is guaranteed to be
> 100% non-debuggable, because, as Pavel pointed out, WinDbg, like any
> other piece of software running on the computer can not see the memory
> used by SMM (except for the handler itself). There is no way that I’m
> aware of to do this without some hardware debugging support, which is no
> at all cheap. I might be able to help you have this sort of support
> already or can get it, but otherwise, there is really nothing that can
> be done without it.
>
> mm
>
>>>> xxxxx@writeme.com 2006-12-14 12:35 >>>
> “Ladkani, Neeraj” wrote in message
> news:xxxxx@ntdev…
>>HI All ,
>>
>>I need to write an driver which makes use of processor SMM mode and
> try
>>to accomplish some functionality implemented by BIOS , I am running
> on
>>multiprocessor and Windows 2003 , which processor will be entered in
> SMM
>>mode and what will happen to the other processor running ? Moreover
> I
>>need to make sure that routine which generate the SMI, should be
> running
>>only on single processor!! since I am filling some registers to
> before
>>generating SMI , Current behavior is system is freezing for ever, I
> am
>>not sure what is the reason ,
>>
>>
>>Has somebody has tried writing an SMI driver on Windows environment?
>>Can somebody tell me, what all thing a driver writer should take care
>>while doing this?
>
> This is quite unusual requirement. SMM is not visible to Windows
> drivers. It is intended for the use of BIOS.
> A driver writer should not get into SMM at all.
> If the functionality you want is available thru ACPI, use that.
>
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

13

>Has somebody has tried writing an SMI driver on Windows environment?

Jake Oshins from MS explicitly forbade using SMM in Windows drivers.

The reason is that SMM handlers belong to mobo/chipset/BIOS, and are often used
to patch the chipset’s issues or to implement some chipset functions like ACPI
EC instead of implementing them in silicon.

For instance, tampering the SMM handlers on cheap laptops can disable the
battery charge control and destroy the device by overcharge.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

In 2003 too, just look at the DDK headers about “ACPI methods”.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Ladkani, Neeraj”
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 14, 2006 9:56 PM
Subject: RE: [ntdev] Regarding SMM mode

Can we make use of a BIOS routine (SMI routine) from ACPI tables? I
heard its possible from VISTA ?

Does anybody know about it ?

Thanks and Regards
~Neeraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladkani, Neeraj
Sent: Friday, December 15, 2006 12:08 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Regarding SMM mode

I agree to the Martin and Pavel ,

But I was not aware if I can use ACPI from win 2k3 , I assumed that
could be done only from Vista ,

Current I am fetching SMI port from ACPI tables, and making use of that
…

Can you tell me, is it possible to use ACPI to use for SMI?

Thanks and Regards
~Neeraj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Thursday, December 14, 2006 11:37 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Regarding SMM mode

NEERAJ:

Pavel is quite correct; off the top of my head, this is probably the
most unsupported aspect of Windows internals that I can think of. All
that being said, how are you getting in to SMM presently? The
essentially terminal issue with SMM is that, unless you have something
like and Arium ECM-50 or some other hardware debugger with SMI support
(which I don’t think is out there), this problem is guaranteed to be
100% non-debuggable, because, as Pavel pointed out, WinDbg, like any
other piece of software running on the computer can not see the memory
used by SMM (except for the handler itself). There is no way that I’m
aware of to do this without some hardware debugging support, which is no
at all cheap. I might be able to help you have this sort of support
already or can get it, but otherwise, there is really nothing that can
be done without it.

mm

>>> xxxxx@writeme.com 2006-12-14 12:35 >>>
“Ladkani, Neeraj” wrote in message
news:xxxxx@ntdev…
>HI All ,
>
>I need to write an driver which makes use of processor SMM mode and
try
>to accomplish some functionality implemented by BIOS , I am running
on
>multiprocessor and Windows 2003 , which processor will be entered in
SMM
>mode and what will happen to the other processor running ? Moreover
I
>need to make sure that routine which generate the SMI, should be
running
>only on single processor!! since I am filling some registers to
before
>generating SMI , Current behavior is system is freezing for ever, I
am
>not sure what is the reason ,
>
>
>Has somebody has tried writing an SMI driver on Windows environment?
>Can somebody tell me, what all thing a driver writer should take care
>while doing this?

This is quite unusual requirement. SMM is not visible to Windows
drivers. It is intended for the use of BIOS.
A driver writer should not get into SMM at all.
If the functionality you want is available thru ACPI, use that.

Regards,
–PA

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

15

Well Max,

Not only do I not have the power to forbid anybody from doing anything, I
don’t think that you’re accurately reporting what I may have said.
Honestly, I think that you’re confusing discussions of SMM and SMBus.
They’re separate, though related, topics.

For the record, here are my feelings on both SMM and SMBus, without going
into so much detail that I can’t get any work done today:

SMM:

SMM stands for “System Management Mode,” which is a mode the processor flips
into in response to a signal from the chipset or a self-directed interrupt.
(I’m not sure the second form is ever used, though the APIC spec allows it.)
In this mode, the BIOS gets control of the entire machine, does
indeterminate things during an indeterminate period of time and eventually
resumes control to the OS. It was used in the past for power management and
configuration, along with various chipset bug fixups. It’s still used for
some power management, though much more in concert with the OS and certainly
for chipset bug fixups. It’s also used for tightly-integrated laptop
features like screen brightness control, speaker volume control, etc. It’s
often the case that laptop-related drivers trigger SMIs to get work done,
passing control to the BIOS for some period of time. Video BIOSes often do
the same sorts of things.

I do actually hold some value judgements here. I think it’s nearly
impossible for the OS to make any soft- or hard-real-time guarantees while
this is going on, though since Windows really doesn’t try to do that anyhow,
we rarely hear that discussed. I also believe that unless there is a really
strong statement about which hardware in the machine the BIOS owns and which
hardware the OS owns, you’ll see instabilities as both the software and the
firmware try to manage the hardware. In general, I’ve spent a lot of my
career trying to define ways to make that ownership contract clearer.
Believe it or not, this is one of the areas that ACPI actually addresses
pretty well. (And yes, I know that ACPI is neither the answer for
everything nor is it without flaws.)

SMBus:

SMBus is a protocol spec for devices that are connected via I2C busses.
They are related to this discussion only in that the SMM BIOS is often the
owner of these devices. The OS rarely interacts with them directly. ACPI
is often the interface between the OS and things like temperature sensors,
battery management systems, etc. In turn ACPI interfaces often invoke SMM
in order to get SMBus-related activity accomplished. I wish this weren’t
so, but I lost that battle a decade ago when the Win98 guys refused to put
the SMBus bus driver into their OS. As a result, Microsoft has almost
entirely gotten out of the business of dealing with SMBus directly. The
SMBus bus driver is no longer in current versions of NT, though it was for
Windows 2000 and Windows XP.

I have in the past and would currently still discourage anyone from trying
to write a Windows driver that interacts with SMBus. You’ll end up in a
battle with the BIOS for control of your device. This is tough to resolve.

  • Jake Oshins
    Windows Kernel Team

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> >Has somebody has tried writing an SMI driver on Windows environment?
>
> Jake Oshins from MS explicitly forbade using SMM in Windows drivers.
>
> The reason is that SMM handlers belong to mobo/chipset/BIOS, and are often
> used
> to patch the chipset’s issues or to implement some chipset functions like
> ACPI
> EC instead of implementing them in silicon.
>
> For instance, tampering the SMM handlers on cheap laptops can disable the
> battery charge control and destroy the device by overcharge.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

16

> Honestly, I think that you’re confusing discussions of SMM and SMBus.

OK, thanks Jake!

Then some questions, which I think can be useful for the whole forum to
understand SMBus/SMM/ACPI EC topic better:

  1. Am I correct that the ACPI machine must have a CPU-independent (even in
    terms of DC power) silicon logic called ACPI Embedded Controller?

  2. Am I correct that one of the purposes of the ACPI EC is - to be the host of
    SMBus, and all other SMBus devices like fan/temperature/battery sensors are the
    slaves of ACPI EC, connected via SMBus wires?

  3. Am I correct that things like fan speed management in Prescott-generation
    mobos (865PE chipset comes to mind) is implemented in ACPI EC? It works
    regardless of the OS booted, even for ACPI-uncapable OSes like FreeBSD with
    non-ACPI kernel build.

  4. Am I correct that the only way for the software (including the kernel-mode
    one) to deal with fan speeds/temperatures/battery levels is - to query the ACPI
    EC via its registers?

  5. Am I correct that the sequences to query the ACPI EC registers are encoded
    to some ACPI methods in the BIOS, and so ACPIEC.SYS can order ACPI.SYS to
    execute them and thus to expose them architecturally to the upper layers of the
    OS like battery drivers or WMI?

Now the last questions:

  1. Am I correct that, despite the requirement of ACPI EC to be CPU-independent,
    it is often - especially on cheap laptops - implemented “virtually”, as a host
    CPU running some BIOS code in SMM mode, to save the silicon space? and that SMM
    is used here to provide full transparency for the OS software, as if it was the
    really separate silicon?

  2. Am I correct that, on such a machine, meddling with SMM will break the ACPI
    EC functionality and cause disastrous results - like switching off the fans
    with subsequent thermal damage or such?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

17

> If you want to verify that you’re getting the right value from the ACPI

tables for the SMI command port, type !fadt in the debugger. One of the
fields listed is the SMI command port. (It may not surprise you to know
that several drivers Microsoft ships have to do this. I worked on most of
them at one time or another.)

  • Jake Oshins
    Windows Kernel Team

Jake,

IMO, the ACPI spec doesn’t require that writing to SMI_CMD port actually
produces an SMI and a transition to SMM. Theoretically switch to/from
legacy/ACPI mode can be done directly by HW/chipset without running any BIOS
code in SMM.

Dmitriy Budko
VMware

18

> Then some questions, which I think can be useful for the whole forum to

understand SMBus/SMM/ACPI EC topic better:

  1. Am I correct that the ACPI machine must have a CPU-independent (even in
    terms of DC power) silicon logic called ACPI Embedded Controller?

No, ACPI EC is an optional component in an ACPI system. It is used mostly in
mobile platforms.

  1. Am I correct that one of the purposes of the ACPI EC is - to be the
    host of
    SMBus, and all other SMBus devices like fan/temperature/battery sensors
    are the
    slaves of ACPI EC, connected via SMBus wires?

Yes.

  1. Am I correct that things like fan speed management in Prescott-
    generation
    mobos (865PE chipset comes to mind) is implemented in ACPI EC? It works
    regardless of the OS booted, even for ACPI-uncapable OSes like FreeBSD
    with
    non-ACPI kernel build.

I don’t know the details here. A system doesn’t need ACPI EC to do fan and
power management. It can use SMM BIOS code and SMM BIOS “device driver” for
for SMBus controller and its slave devices.

  1. Am I correct that the sequences to query the ACPI EC registers are
    encoded
    to some ACPI methods in the BIOS, and so ACPIEC.SYS can order ACPI.SYS to
    execute them and thus to expose them architecturally to the upper layers
    of the
    OS like battery drivers or WMI?

It is probably correct.

Now the last questions:

  1. Am I correct that, despite the requirement of ACPI EC to be CPU-
    independent,
    it is often - especially on cheap laptops - implemented “virtually”, as a
    host
    CPU running some BIOS code in SMM mode, to save the silicon space? and
    that SMM
    is used here to provide full transparency for the OS software, as if it
    was the
    really separate silicon?

I don’t know about how common is such design but such design is definitely
possible.

BIOS does similar thing for emulating PS/2 devices and legacy PS/2 IO ports
with USB devices. It will run a small USB stack in SMM mode if the OS doesn’t
control the USB host controller.

  1. Am I correct that, on such a machine, meddling with SMM will break the
    ACPI
    EC functionality and cause disastrous results - like switching off the
    fans
    with subsequent thermal damage or such?

Yes, it is possible. Nevertheless, many modern HW devices (modern CPUs and
lithium batteries for example) have fail-safe HW-based protection against
overheating.

Dmitriy Budko
VMware

19

>6) Am I correct that, despite the requirement of ACPI EC to be
CPU-independent, it is often - especially on cheap laptops - implemented
“virtually”, as a host CPU running some BIOS code in SMM mode, to save

the silicon space? and that SMM is used here to provide full
transparency for the OS software, as if it was the really separate
silicon?

  1. Am I correct that, on such a machine, meddling with SMM will break
    the ACPI EC functionality and cause disastrous results - like switching
    off the fans with subsequent thermal damage or such?

EC is a micro controller running independent using its own instruction
set in its own EEPROM. There are also designs that the EC code resides
in BIOS ROM chip.
EC usually contains the keyboard controller logic, battery
charge/monitor logic, laptop hot-key logic, and some has built-in
hardware monitor(temp, fan…etc).
The term “ACPI-EC” merely means the EC is described in ACPI language so
that OS can recognize and utilize it.

SMM is pure x86 mechanism. Once SMI is triggered, CPU switches into big
real mode immediately, and control goes to BIOS defined “physical”
memory location where the SMI handler is executed.
A robust BIOS writes its SMI handler to skip unrecognized software SMI,
triggered by “out dx,ax” where dx is smi port and ax is the command.
I don’t think it would be an easy task, even in DOS, to modify the SMI
handler since it requires chipset-dependent knowlegde to turn on/off
some noththbridge registers.

TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

20

>> slaves of ACPI EC, connected via SMBus wires?

Yes.

So, ACPI EC and SMBus controller are different things?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com