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