From: Sheng Yang <sheng@linux.intel.com>
To: kvm@vger.kernel.org
Cc: Jun Koi <junkoi2004@gmail.com>, Xiaodong Yi <xdong.yi@gmail.com>
Subject: Re: Luvalley project: running KVM without Linux
Date: Thu, 26 Mar 2009 12:19:04 +0800 [thread overview]
Message-ID: <200903261219.05164.sheng@linux.intel.com> (raw)
In-Reply-To: <fdaac4d50903252056r343e07f8k8709d6ae771d2e45@mail.gmail.com>
On Thursday 26 March 2009 11:56:20 Jun Koi wrote:
> Very cool! Who is behind this project? Intel?
Not us...
According to http://lists.centos.org/pipermail/centos-promo/2009-
February/000402.html, it is "the Operating System Engineering Research Center
in China."
--
regards
Yang, Sheng
>
> I will give it a try!
>
> Thanks,
> Jun
>
> On Thu, Mar 26, 2009 at 12:20 PM, Xiaodong Yi <xdong.yi@gmail.com> wrote:
> > 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@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-03-26 4:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 3:20 Luvalley project: running KVM without Linux Xiaodong Yi
2009-03-26 3:56 ` Jun Koi
2009-03-26 4:19 ` Sheng Yang [this message]
2009-03-26 6:55 ` Xiaodong Yi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200903261219.05164.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=junkoi2004@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=xdong.yi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox