[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.0901271249460.19655@localhost.localdomain>
Date: Tue, 27 Jan 2009 13:00:42 -0500 (EST)
From: Len Brown <lenb@...nel.org>
To: Jon Masters <jcm@...hat.com>
Cc: linux-rt-users@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
williams <williams@...hat.com>,
"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
Subject: Re: [RT] [RFC] simple SMI detector
Is it possible that if the detector is running,
it may prevent (delay) the thing it is trying to detect?
Eg. some random AML gets interpreted by the kernel,
it needs to touch an MSR, but MSRs are not accessible
from AML, so it triggeres an SMI by touching a magic IO address
with a magic value.
So in this case, the random AML may not run until after
the detector has stopped running, because the detector
prevented some random user-space distro value-add
from polling the battery or the temperature or something...
The other example that comes to mind is that dreaded
USB PS/2 emulation done via SMM.
FWIW I detest SMM as much as any OS person should.
But I also acknowledge that it is virtually impossible to prevent
BIOS developers from giving it up. We OS types have proposed an
"SMI has happened bit or counter" many times,
even though we'd rather have a "SMM disable" bit:-)
cheers,
--
Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists