[Barrelfish-users] Barrelfish : Virtualization Firmware

Guillaume FORTAINE gfortaine at live.com
Thu Dec 24 22:33:31 MET 2009


Misters,

Let me introduce myself : Guillaume FORTAINE, Engineer in Computer
Science. I am currently working on a Virtualization Firmware.

Virtualization is currently the new trend in computing, the market is
worth multi-billion dollars (~3.5 by combining Citrix and VMWare's
revenues, the leaders of the business), and a bare-metal hypervisor is
the holy grail for Virtualization providers.  To quote Forbes Magazine [0]:

"By next year, estimates Gartner, half of all serverbased computing
will be on virtual machines."

After an analysis of the various solutions (Citrix, VMware and Red
Hat), it seemed natural to my eyes. to enable a true bare-metal
hypervisor, to go as close as possible to the hardware, hence the
BIOS.

To quote a Google BIOS Engineer [1]

"I also agree that right place for VM is in the firmware.  I tried to
get it in the BIOS in my previous job (AMI) but didn't go through."


Moreover, by including it directly at the firmware level, instead of
relying on 3rd party partners, a company could leverage a very
valuable new source of revenue by licencing it.

The value-added for  the company's customers would be an
high-performance, dependable and lower cost alternative to
inefficient, complex and costly Virtualization Solutions (Citrix
XenServer, VMWare ESX Server (2250 USD), Microsoft Server 2008 R2 with
Hyper-V (2500 USD), Red Hat Enterprise Virtualization Hypervisor =
REVH (500 USD) [2])


I) Virtualization Firmwares

1) Comparison

At the current time, there are currently four Virtualization Firmwares
design proposals.

a) Hypervista : UEFI Hypervisor [3]

I am definitely aware about the UEFI Forum and especially the
Hypervista's effort to implement an UEFI Hypervisor. From my analysis,
Hypervista is of particular interest as business case for an SMB
trying to innovate around UEFI.  Their effort has been a failure and I
am not surprised, because three years ago (in 2006), I was the first
to post on the edk2 website to kindly ask some hardware support from
the UEFI Forum [4]. To quote the reply from an Intel engineer [5]:

"The Edk2 project on www.TianoCore.org does not have silicon enabling
code but it does implement UEFI conformant interfaces. It currently
builds under Windows, Linux, and Mac OS X. So this code may be helpful
to you."

The first point is to show you that I followed the UEFI's effort since
the beginning and that as an individual, I tried to contribute to
something new. And I didn't receive any support. What is the point of
a Platform Initialization software that doesn't provide any hardware ?
At least an Intel Customer Reference Board with an initial UEFI port
would have been an invaluable help to provide further innovation. Two
years later, the situation was the same for Hypervista. To quote [3] :

"During our recent search for a UEFI compliant PC motherboard, even
Intel®, AMI®, and Phoenix® had difficulty identifying PC motherboards
that support UEFI 2.x in June 2008."



b) Coreboot AVATT [6]

This Google Summer of Code project suggested the idea of implementing
a Linux kernel with KVM (Kernel Virtual Machine to provide Type I
Hypervisor abilities to Linux) as a coreboot payload (=Virtualization
inside the BIOS)



c) Google Platforms Virtualization Firmware [7]

Philip Wells ( http://research.google.com/pubs/author38014.html ), 
Software Engineer
inside Google Platforms group [8], proposed a Virtualization firmware 
design for multicore
chips in his Ph. d thesis entitled : "ADAPTING TO DYNAMIC
HETEROGENEITY: VIRTUALIZATION FOR THE MULTICORE ERA"


d) coresystems virtualcore

To quote [9] :

"virtualcore of coresystems GmbH puts virtualization exactly where it
belongs: Into the firmware.

Deploy your appliances and products directly to new hardware - without
headaches due to the underlying technology.

Scalability through high-end technology on your x86 bases server systems."




2) Conclusions

My conclusions are the following ones :

a) UEFI

Tianocore can't boot and we can't use it on a real system.


b) coreboot

To date, there was no case of large scale adoption of coreboot and
Intel gave the main reason. To quote [10]:

"And with the GPL issues around intellectual property, hardware
vendors and OEM's will be unlikely to adopt LinuxBIOS going forward."



c) Google Platforms

Google Platforms is not going to collaborate, because everything they do in
hardware is proprietary.



d) coresystems GmbH virtualcore

It is a fork of coreboot AVATT knowing that coresystems GmbH is the
main commercial sponsor of coreboot.




3) Solution

I can see that the main concern for Hardware Vendors to deploy
coreboot is not because it is open source, but, because it is under a
GPL License.

A BSD-style Open Source licence would be the right licencing basis,
because it will let Hardware Vendors (CPU, Chipset, OEMs, IHVs)
protect innovation.

Unfortunately, the coreboot project is tied to the GPL due to the
presence of Linux Kernel code and a reengineering of the code to be
compatible with a BSD-style Open Source licence would need an amount
of support not sustainable ( the estimation is 5 people / 4 million $
USD / 3 years) for a possible firmware strategic direction even for
the largest global technology companies.

Concluding that neither UEFI nor coreboot provide a convenient answer
to both the technical (UEFI) and business (coreboot) sides of Firmware
Engineering, I am planning to develop a firmware from scratch licensed
under BSD (business side in mind) and whose APIs are derived from a
microkernel (technical side in mind).

To quote [11] :

"- UEFI has to provide network/disk/video drivers which can/should be
used by the OS."

A Virtualization Firmware derived from a Microkernel will provide
the well-defined APIs of an Operating System, by example Mackerel
from Barrelfish [12].

And it has already been done : cf the Redboot Bootloader derived from 
eCos [13]

Moreover, designing the virtualization firmware around the Barrelfish OS 
with VMkit Hypervisor [14]
instead of Linux with KVM could be the perfect match. Not only because 
Barrelfish
will be scalable for massively multicore chips (like the forthcoming
Intel Cloud Computing Chip) and could perfect fit inside the design
principles suggested by Philip Wells from Google Platforms in his
thesis [7], but also, because it is licensed under a 3-clause BSD-style 
Open Source licence.
Thanks to a sponsor, and after a licensing agreement, the concept would 
become patentable, something
that was impossible with Linux + KVM (under GPL).


Virtualization Firmware = (Redboot based on Barrelfish (Platform 
Initialization) +
Barrelfish with VMkit (Virtualization)) under a BSD-License.


Moreover, I am currently setting up a strong ecosystem around me, 
including key
members of the UEFI Forum (HP for funding, AMD and Microsoft Cambridge
for technical support).

This Virtualization Firmware could revolutionize the industry.

I look forward to your answer,

Merry Christmas,

Best Regards,

Guillaume FORTAINE

[0] 
http://www.forbes.com/forbes/2009/1228/technology-virtualization-vmware-wyse.html
[1] http://www.google.com/profiles/sivagar
[2] http://www.virtualization.info/2009/11/red-hat-releases-enterprise.html
[3] 
http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/
[4] 
https://edk2.tianocore.org/ds/viewMessage.do?dsForumId=139&dsMessageId=13751
[5] 
https://edk2.tianocore.org/ds/viewMessage.do?dsForumId=139&dsMessageId=13804
[6] http://www.coreboot.org/AVATT
[7] ftp://ftp.cs.wisc.edu/sohi/theses/pwells.pdf
[8] http://www.google.com/support/jobs/bin/answer.py?answer=46705
[9]  http://www.coresystems.de/en/virtualcore
[10] http://www.uefi.org/learning_center/A_Tale_of_Two_Standards.pdf
[11] http://www.coreboot.org/pipermail/coreboot/2009-September/052150.html
[12] 
https://www.systems.ethz.ch/education/theses/making-device-drivers-safer
[13] http://en.wikipedia.org/wiki/RedBoot
[14] http://www.barrelfish.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20091224/8d0647ca/attachment.html


More information about the Barrelfish-users mailing list