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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
