[coreboot] SMM handling and resident coreboot

[Stefan Reinauer]

ron minnich wrote:
> If you think about it, SMI, VSA, ACPI, EFI, and even the old BIOS --
> all are there to virtualize resources that in some cases don't even
> exist, but in other cases are non-standard. I am wondering about
> stepping back from the problem and going at it with this approach --
> that a runtime BIOS is really there to virtualize resourcs.
Yes, but that is also what drivers do. They unify the way your high
level software talks to the hardware. On top of that, multi tasking
pretends to provide several computers, each running a single program.

> Viewed
> this way, the answer is somewhat easier. The runtime BIOS can be a
> hypervisor. The models supported by these many varying systems are
> viewed as subset functions of a  hypervisor.
>   

You can use some of the features to model a hypervisor, but the fact
that a bios consists of drivers that control hardware has nothing
directly to do with a hypervisor. Running a hypervisor on top of the
hardware initialization is a good approach, but basically what it boils
down to is: where to get the drivers.

> If this seems crazy, it is actually the approach used in the PS/3. is
> that good or bad?
>   
What exactly?

> Where do we get a hypervisor? From the Xen guys, for one choice.
>   

> Just a thought. Rather than merely redo old ideas like SMI and
> old-style BIOS, we could step out ahead and do something very
> powerful.
>   

We could probably teach XEN to understand SMI#s occuring and handle
their virtual instances accordingly. But what would be the gain?

I fear there is some confusion about what SMI really is.

SMI is not an old style idea. It's simply a mechanism to get an
interrupt when for example your battery is low, or a hot plug event has
happened.

And the nice thing is: It is a very standard way of doing things. This
will work across cpus and chipsets with a moderate amount of changes to
make things happen.

Well, you can sure go the way of polling if you say that having an
interrupt is an old style idea, or say that you want to implement that
interrupt handler in your favourite operating system. Unfortunately this
is not the way operating systems handle things these days.

If you are on an Intel chipset and you want to implement ACPI based on
the ACPI standard and Linux implementation, you will have to use an SMI
handler, there is no way whatsoever around this. Well, except writing
native drivers for highly mainboard and wiring specific stuff in Linux,
in Plan9, in *BSD, in Windows XP, in Windows Vista, in [fill your
favourite OS or payload].

Yes, it steals cycles. Yes, it is not good for hard realtime
applications. Just like any other interrupt. Well, obviously if you want
to run RT applications on a current desktop or laptop mainboard you have
to ensure that your application does not care for power management or
anything related to it.

If you want power management features, you will either have to throw a
lot of hardware development of the last 10 years overboard and start
with a new revolutionary approach, or you will need someone to take care
of those events, even if the OS is not capable of taking care.

The good thing is: you're going to have the choice. With other
approaches out there (your fav. bios vendor) you end up with an SMI
handler even if you boot your system with acpi=off.


I believe at some point we should very well discuss how we can really
change the whole picture by stepping back and looking at the big picture
and getting something really smart out of it, that noone else did think
about before. But, if nothing else, this is a good finger exercise for
us as a community to learn how things generally work, and then we can
take the next step.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866