Hello,
On Wed, 2008-06-18 at 14:14 +0200, Stefan Reinauer wrote:
ron minnich wrote:
are you ready to go? We are supposed to have started.
any news?
These days I just finished my graduation stuff, so that now I can start working full time on my GSoC project.
This is what I have in mind, for anyone who may be interested about this topic and cannot read my GSoC application's discussions:
My project (AVATT) involves creating a small KVM-aware Linux payload, integrating in the initrd the tools needed to create and run virtual machines, straight on top of the BIOS.
The first part is about making everything as small as possible, aiming it to fit in under 1 MB, but as smaller it gets, as better.
The Linux kernel minimization part is quite trivial, there are those tiny patches which can easily make it a few hundreds of kilobites, and some careful drivers selection.
Still some work needs to be done on the minimization of the KVM tools. Their dependencies on high-level userspace stuff like SDL must be eliminated, and they must be statically linked with some small libc. I'm thinking about uclibc, but any other ideas are welcome.
Then, I was thinking about making some small GNU screen-like tool that would allow the user to quiclky create (wizard?), attach and switch between virtual mahines. This would be great for console-only OS-es, but i guess that more serious ones should be able to use real tty's, if needed, just like X is doing for its display. Xen's tools, dtach and GNU screen may be considered as reference for this kind of tool. Ideally, the system should allow multiplexing any other devices, like sound, USB, etc, but this must be further investigated.
I already have a testbed installation that uses qemu to emulate a amd64 box. Latest qemu supports virtualization itself, and I already succeeded to run double emulation with it, as a proof of concept. The performance is awful, but it works. Anyway, the final part will need a powerful amd64 machine that should be used for testing the real stuff.
If you have any suggestions and questions to ask, feel free to do it.
Best regards, Cristi
Let's keep it very simple to start. The main goal is to provide kvm support from coreboot immediately, and allow users to start up VMs from a shell prompt at boot. I think if you get this going, people will add a lot of good work.
It's essential that we get this working on real hardware in the long term, even more important than the nice GUI at first; what have we chosen as a target?
Also, it is very important that at certain "breakpoints" on the way, we make sure others can replicate your work. This type of testing allows catches important problems. So a "recipe" at these breakpoint stops that others can use to duplicate your setup would be a great idea.
Thanks, this is a wonderful project and we are very happy to have you working on it.
ron
On Wed, 2008-06-18 at 09:55 -0700, ron minnich wrote:
Let's keep it very simple to start. The main goal is to provide kvm support from coreboot immediately, and allow users to start up VMs from a shell prompt at boot. I think if you get this going, people will add a lot of good work.
Okay, That's how I've thought too, those ideas were on the long run, but first I must solve the basic problem of running a KVM Linux payload.
It's essential that we get this working on real hardware in the long term, even more important than the nice GUI at first; what have we chosen as a target?
Anything AMD64-based that can run KVM-qemu over coreboot2 should do. Please someone who owns this kind of boards with coreboot2 test the KVM support and write in the wiki if it works, and I'll buy the one that is best supported by coreboot.
Anyway, for this stage that I'm in qemu is the perfect tool. The real box will only be needed a bit later.
Qemu can easily run a dually emulated Linux kernel (vm inside vm), and that's everything I need for now. A simple kernel should work just fine. My original test involved a guest VM with a full desktop runing inside it, that's why it was that slow.
Also, it is very important that at certain "breakpoints" on the way, we make sure others can replicate your work. This type of testing allows catches important problems. So a "recipe" at these breakpoint stops that others can use to duplicate your setup would be a great idea.
Okay, I'm going to make a wiki page where I'll document whatever I'm doing, so please someone make me a wiki account. I'd like to have the username "alien", if possible ;) (that's my IRC nickname too)
Thanks, this is a wonderful project and we are very happy to have you working on it.
I also think the same, this project has a huge coolness factor and I'm very glad that I was chosen to make it happen, but even more to get involved in coreboot.
Cristi
-
Cristi Magherusan -
ron minnich