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

[Paolo Bonzini <pbonzini@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

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.

So is having a special QEMU binary with fewer runtime dependencies,
though that should only be a stopgap measure; the real solution is to
modularize e.g. the UI and audio subsystems to remove runtime
dependencies from the QEMU binary itself.

I agree with Stefan however that there should be no special machine
types or kernels.

Referring to your slides, the remaining points for fast boot are:

* parallelize VCPU initialization: do you have patches? :)

* q35-lite: any other machine options that have not been merged yet?

* SeaBIOS+Option ROM: can you take new numbers with DMA-based option
ROM, or with qboot?

* guest kernel: my proposal to make Linux a multiboot kernel has been
nacked upstream, but Oracle is working on supporting Xen PVH binaries in
QEMU.  These are very similar to multiboot and in particular they're
uncompressed.

For memory consumption, 2.11 should have improved things already thanks
to shared FlatViews.  Your malloc_trim patch should also be merged in 2.12.

So are things really that bad?  Almost all "qemu-lite" patches that have
been proposed upstream have been accepted.

Only mmap-ing the kernel into the guest is not going to be accepted, but
maybe you can look into replacing stdio with open+mmap in load_linux and
load_multiboot, for both the kernel and the initrd.  This should save a
few milliseconds too.

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]