public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John <linux.kernel@free.fr>
To: linux-kernel@vger.kernel.org
Cc: linux.kernel@free.fr
Subject: Disabling x86 System Management Mode
Date: Mon, 16 Apr 2007 12:47:35 +0200	[thread overview]
Message-ID: <46235447.3080000@free.fr> (raw)

Hello everyone,

According to Wikipedia:
http://en.wikipedia.org/wiki/Non-Maskable_Interrupt
http://en.wikipedia.org/wiki/System_Management_Mode

"SMM is an operating mode of the Intel 386SL and later microprocessor in 
which all normal execution (including the operating system) is 
suspended, and special separate software (usually firmware or a 
hardware-assisted debugger) is executed in high-privilege mode.

Operations in SMM take CPU time away from the OS, since the CPU state 
must be stored to memory (SMRAM) and any write back caches must be 
flushed. This can destroy real-time behavior and cause clock ticks to 
get lost."

AFAIU, even a hard real-time OS is "defenseless" against SMIs that
kick the CPU into SMM.

I'm planning on writing a few line of code to gather indirect evidence
that the CPU is periodically entering SMM.

I was considering a kernel module along the lines of...

for (i=0; i < N; ++i)
{
   schedule_timeout(1); /* sleep at least one jiffy */
   disable interrupts
   unsigned cycles = foo();
   /* update stats with cycles */
   enable interrupts
}

foo is a loop full of NOPs.
It takes up only a few lines in L1 cache.
The conditional jump is easy to predict.
There is a serializing instruction before and after.
As a result, foo's latency should be very consistent.
foo returns the number of cycles it ran. On the systems I have to work 
with, foo typically runs in ~800 microseconds.
I suppose disabling interrupts that long is bound to break something 
somewhere?

.globl foo
foo:
   push %ebx
   push %esi
   cpuid
   rdtsc
   mov MM, %ecx
   mov %eax, %esi
.align 16
.L1:
   nop
   nop
   ... (lots of nops)
   dec %ecx
   jnz .L1
.L2:
   cpuid
   rdtsc
   sub %esi, %eax
   pop %esi
   pop %ebx
   ret

If foo returns something out of the ordinary, even though interrupts 
were disabled, then it must have been interrupted by a non-maskable 
interrupt, probably a system management interrupt.

What do you think about this approach?
I'm open to comments and suggestions.

Regards.

             reply	other threads:[~2007-04-16 10:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-16 10:47 John [this message]
2007-04-16 11:31 ` Disabling x86 System Management Mode John
2007-04-16 15:12   ` Lee Revell
2007-04-16 22:12 ` Andi Kleen
2007-04-17 16:49   ` John Sigler
2007-04-17 16:57     ` Andi Kleen
2007-04-17 21:32       ` John Sigler
2007-04-17 17:01     ` John Sigler
2007-04-18  8:09     ` John Sigler
2007-04-18 11:41   ` John Sigler
2007-04-18 14:06     ` Andrew Shewmaker
2007-04-18 14:39       ` John Sigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46235447.3080000@free.fr \
    --to=linux.kernel@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox