Slashdot Mirror
Ask Kevin Lawton About Plex86
Kevin Lawton, currently employed by MandrakeSoft, is the creator and driving force behind Plex86, the Open Source X86 virtualization software which runs under Linux and now boots several operating systems, including QNX and Windows 98. This is a tricky endeavor, because (among other things), as the plex86 site states: "The x86 processor is not 'naturally' virtualizable. That is to say, it was not designed to run multiple operating systems concurrently." But with enough feints and jabs, Kevin and company have cajoled it into doing so anyhow. He's agreed to answer your questions about virtualization (and / or emulation -- he is the guy behind the also-Open Source bochs project to emulate X86 processors), so please post your stumpers below. Make sure to check out the Plex86 website first, and perhaps read other things about Plex86 on Slashdot. (And "What's the point?" is not a stumper.)We'll forward the top questions on to Kevin, and hear back from him soon.
Are there any plans in the near future to replace the Elpin BIOS with a Free implementation?
--
The need for large partitions in a Windows environment coupled with the file size limits in Linux and the more restrictive Windows licensing means this sort of support is critical to anyone wanting to run Windows on Linux with plex86.
--
On a processor, you have facilities like general registers, that the emulated operating system is supposed to use, and that will be saved and restored by the control program when you switch contexts.
You also have certain special registers and facilities, like control registers, and segment registers. The actual contents of these registers are going to always remain under the control of the supervisor. Part of the job of a virtualization supervisor is to emulate the function of these registers, and also to reflect their virtual state to the virtualized operating system when requested.
So basically, in order for the architecture to be virtualizable, all of the instructions that expose the presence of the emulator must be privileged.
This includes things like control registers, status words, I/O instructions, etc. If you're going to "fake out" an operating system into believing that it is running on bare iron, you need to be able to generate an exception whenever the operating system attempts to execute an instruction that exposes the fact that the actual state of the processor is different from the state of the virtual machine.
For instance, one of the mistakes in the IBM System/370 architecture was that the instruction for accessing the hardware time-of-day clock (STCK -- STore ClocK) was a non-privileged instruction. As a consequence, it was impossible to set a different time of day for a virtual machine -- the supervisor couldn't trap the instruction.
Some architectures (I believe that this is one of the X86 sticking points) require privileged state in order to modify certain control registers, but provide non-privileged instructions for accessing the contents of those registers.
For non-virtualizing operating systems, this makes sense. By making the instructions to examine the system state non-privileged, you both simplify the job of writing the operating system (because you don't have to emulate those instructions), and you also receive a performance boost (because executing those instructions don't result in exceptions). The tradeoff comes when you try and implement a virtual machine environment, and find that you can't, because even in protected mode, a program can find out "too much" about the actual state of the processor.
If the authors of an OS want to cooperate with Plex86, so it runs more efficiently when virtualized, what would you recommend? What (expensive) operations would be best avoided? Will Plex86 have a API available for a faster alternative to emulation?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I'm an avid FreeBSD enthusiast, and I'm disappointed to see that Plex86 doesn't look like it will run under FreeBSD any time soon. Bochs, on the other hand, works fine under FreeBSD, but lacks many essential features that Plex86 appears to have. I was wondering what you will be doing (if anything) to ensure the platform independence of Plex86. Will you be leaving Bochs as the multi-platform solution? Will the Bochs be abandoned in favor of Plex86?
...These aren't the droids you're looking for....Move along....
Hi Kevin,
/. cast of thousands help out?
What are the greatest needs in the Plex86 project? How can the
(Ok Kevin, here's your chance - you'll never get a better one to recruit new helpers!:-)
I know this is a way off, but do you see any reason why DirectX support would not be possible? Or would it just require too much manpower that it wouldn't be feasable?
A topic brought up on Slashdot a couple days ago had some interesting discussion that if Free solutions like Plex86 took off, it would destroy VMWare's business model, and show other businesses that you can't make money developing software for Linux because someone will undercut you with a Free solution. How do you respond to these fears?
NO CARRIER
While the ideal is that Plex86 will support all operating systems, I assume that you've made choices as to which ones you're going to work on first. Your site mentioned Dos, NT, Win95, Linux and QNX as OSes that PLex86 currently runs. As someone who tends to use FreeBSD when I use a free OS, I'm curious as to where the BSDs rate in your priorities and what about BeOS, Plan 9, etc...