qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Luvalley-5 has been released (with whitepaper!): enabl


From: Xiaodong Yi
Subject: Re: [Qemu-devel] Luvalley-5 has been released (with whitepaper!): enables arbitrary OS to run VMs without any modification
Date: 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
Linux.

Regards,

Xiaodong

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
>>  http://sourceforge.net/projects/luvalley/
>>
>> 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.
>
> Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]