[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Luvalley-5 has been released (with whitepaper!): enabl
Re: [Qemu-devel] Luvalley-5 has been released (with whitepaper!): enables arbitrary OS to run VMs without any modification
Sat, 23 Jan 2010 20:07:51 +0800
Thanks for your advice. I'm now preparing to update the Qemu for
Windows (not started yet). I originally though it should be better to
use Qemu-KVM in Linux because, for example, Qemu-KVM supports SMP
guests. I will review the newest Qemu version before updating Qemu for
2010/1/21 Alexander Graf <address@hidden>:
> On 21.01.2010, at 15:19, Xiaodong Yi wrote:
>> Luvalley is a lightweight type-1 Virtual Machine Monitor (VMM).
>> 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.
>> Any operating system, including Linux, could be used as
>> Luvalley's scheduler, memory manager, physical device driver provider
>> and virtual IO device
>> emulator. 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.
>> From the point of view of Qemu, Luvalley enables Qemu to utilize the
>> Intel's VT extension to gain much better performance.
>> If you are interested in Luvalley project, you may download the source
>> codes as well as the whitepaper from
>> The main changes of this release (Luvalley-5) are:
>> * The code derived is updated from KVM-83 to KVM-88
> It might be a better idea to use upstream kernel sources as basis. The KVM
> snapshots are rather deprecated FWIW.
> Is the code to leverage Luvally vastly different from the accessors for KVM?
> Maybe it'd be enough to have a wrapper for kvm_ioctl() that sends ioctls off
> to Luvally instead of KVM to make the existing infrastructure work. That way
> upstream support should be a no-brainer and you get all the upstream qemu
> work for free.
> Also, this would finally make the windows builds more useful again.