Luvalley is a Virtual Machine Monitor (VMM) spawned from the KVM project. Its part of source codes are derived from KVM to virtualize CPU instructions and memory management unit (MMU). However, its overall architecture is completely different from KVM, but somewhat like Xen. Luvalley runs outside of Linux, just like Xen's architecture, but it still uses Linux as its scheduler, memory manager, physical device driver provider and virtual IO device emulator. Moreover, Luvalley may run WITHOUT Linux. In theory, any operating system could take the place of Linux to provide the above services. Currently, Luvalley supports Linux and Windows. That is to say, one may run Luvalley to boot a Linux or Windows, and then run multiple virtualized operating systems on such Linux or Windows.
If you are interested in Luvalley project, you may download the source codes from http://sourceforge.net/projects/luvalley/ The following is more details about Luvalley. Luvalley is an external hypervisor, just like Xen (http://www.xen.org). It boots and controls the X86 machine before starting up any operating system. However, Luvalley is much smaller and simpler than Xen. Most jobs of Xen, such as scheduling, memory management, interrupt management, etc, are shifted to Linux (or any other OS), which is running on top of Luvalley. Luvalley gets booted first when the X86 machine is power on. It boots up all CPUs in SMP system and enables their virtualization extensions. Then the MBR (Master Boot Record) is read out and executed in CPU's virtualization mode. Following this way, a Linux (or any other OS) will be booted up at last. Luvalley assigns all physical memory, programmable interrupt controller (PIC) and IO devices to this priviledged OS. Following Xen, we call this OS as "domain 0" (dom0) OS. Like KVM, a modified Qemu is running on dom0 Linux to provide virtual IO devices for other operating systems running on top of Luvalley. We also follow Xen to call these operating systems "domain user" (domU). That is to say, there must be exact one dom0 OS and may be several domU OSs running on top of Luvalley. Each domU OS corresponds to a Qemu process in dom0 OS. The memory of domU is allocated from dom0 by Qemu. And when Qemu is scheduled to run by dom0 Scheduler, it will call Luvalley to run the corresponding domU. Moreover, as Luvalley requires nothing from the dom0 Linux kernel, other operating systems such as Windows, FreeBSD, etc can also serve as dom0 OS, provided that Qemu can be ported to these operating systems. Since Qemu is an userland application and is able to cross platform, such porting is feasible. Currently, we have added the Luvalley support into Qemu-0.10.0, which can be compiled and run in Windows. With the help of Luvalley, Qemu-0.10.0 runs much faster becuase it could utilize the VT support provided by Intel CPU. In summary, Luvalley inherited all merits from KVM. Especially, Luvalley is very small and simple. It is even more easy-to-use than KVM because it does not depend on specific Linux kernel version. Every version of Linux can serve as Luvalley's dom0 OS, except that Qemu cannot run on it. In addition, we think Luvalley's architecture meets the demand on both desktop and server operating system area: 1. In the desktop area, there are many kinds of operating systems runing on various hardwares and devices. In theory, it is rather easy to add virtualization ability for all kinds of operating systems, without sacrificing the hardware compatibility and the user experience. Moreover, Luvalley is very easy to install. It requires only a boot loader which supports Multiboot Specification, e.g., Grub, WinGrub (http://sourceforge.net/projects/grub4dos), etc. 2. In the server area, especially for large-scale server systems (for example, throusands of CPUs), a single Linux is not suitable to manage the whole system. Therefore, KVM cannot be used properly. Luvalley's architecture is more suitable for servers. For example, it can be used to divide physical resources to partitions, and run a Linux for each partition. In addition, Luvalley is very small and may be put into BIOS to serve as a virtulization firmware. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html