qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] About the light VM solution!


From: Paolo Bonzini
Subject: Re: [Qemu-devel] About the light VM solution!
Date: Tue, 5 Dec 2017 15:00:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 05/12/2017 14:47, Stefan Hajnoczi wrote:
> On Tue, Dec 5, 2017 at 1:35 PM, Paolo Bonzini <address@hidden> wrote:
>> On 05/12/2017 13:06, Stefan Hajnoczi wrote:
>>> On Tue, Dec 05, 2017 at 02:33:13PM +0800, Yang Zhong wrote:
>>>> As you know, AWS has decided to switch to KVM in their clouds. This news 
>>>> make almost all
>>>> china CSPs(clouds service provider) pay more attention on KVM/Qemu, 
>>>> especially light VM
>>>> solution.
>>>>
>>>> Below are intel solution for light VM, qemu-lite.
>>>> http://events.linuxfoundation.org/sites/events/files/slides/Light%20weight%20virtualization%20with%20QEMU%26KVM_0.pdf
>>>>
>>>> My question is whether community has some plan to implement light VM or 
>>>> alternative solutions? If no, whether our
>>>> qemu-lite solution is suitable for upstream again? Many thanks!
>>>
>>> What caused a lot of discussion and held back progress was the approach
>>> that was taken.  The basic philosophy seems to be bypassing or
>>> special-casing components in order to avoid slow operations.  This
>>> requires special QEMU, firmware, and/or guest kernel binaries and causes
>>> extra work for the management stack, distributions, and testers.
>>
>> I think having a special firmware (be it qboot or a special-purpose
>> SeaBIOS) is acceptable.
> 
> The work Marc Mari Barcelo did in 2015 showed that SeaBIOS can boot
> guests quickly.  The guest kernel was entered in <35 milliseconds
> IIRC.  Why is special firmware necessary?

I thought that wasn't the "conventional" SeaBIOS, but rather one with
reduced configuration options, but I may be remembering wrong.

Paolo

> I'm not against additional binaries if there's no other way, but it's
> important to demonstrate why special-casing is necessary.
> 




reply via email to

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