[Kata-hypervisor] Link to the Hypervisor Prototype

Anthony Liguori aliguori at amazon.com
Wed Jun 6 21:00:02 UTC 2018


"Ernst, Eric" <eric.ernst at intel.com> writes:

> Hey Sasha, Anthony –
>
> I want to set a bit of context here.  At the face to face discussion
> in Vancouver, we had agreed to share the prototyping we have put in
> place to better understand how far we could go to remove legacy, and
> minimize the number of device models, while still booting key
> workloads.  Manohar’s response is to address the action that everyone
> in the meeting requested.

Yup, appreciate the sharing and am disappointed I wasn't able to attend
in person.  I'm sure Paolo gave you lots of great feedback but let me
expand a bit on why I think this is the wrong approach.  Ultimately, you
are certainly free to continue down this path though but just thought
you may find this useful.

The pieces of QEMU that are easy to remove are largely already
configurable at build time.  From a practical perspective, if you build
your "prototype" and measure the resulting executable size compared to a
minimalistic configuration, you will find very little actual reduction
in code.

The stuff that's hard to remove is deeply ingrained (like QMP and QOM)
or parts that are just hairy (like vl.c).  Years of effort have gone
into decoupling these bits.

So you get very little actual benefit (in code size reduction) by
forking but get to bare the burden of independent maintenance.

Regards,

Anthony Liguori


>
> Cheers,
> Eric 
>
> On 6/6/18, 1:46 PM, "Sasha Levin" <Alexander.Levin at microsoft.com> wrote:
>
>     On Wed, Jun 06, 2018 at 08:08:46PM +0000, Castelino, Manohar R wrote:
>     >Folks,
>     >
>     >Please find below the link to the initial prototype code that tries to reduce the number of emulated devices in QEMU that can still boot most cloud workloads.
>     [snip]
>     
>     Out of curiousity, have you looked at kvmtool
>     (https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/)?
>     
>     Forking qemu rather than building on top of it (or using something else)
>     isn't going to end well IMO.
>     _______________________________________________
>     Kata-hypervisor mailing list
>     Kata-hypervisor at lists.katacontainers.io
>     http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-hypervisor
>     
>
> _______________________________________________
> Kata-hypervisor mailing list
> Kata-hypervisor at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-hypervisor



More information about the Kata-hypervisor mailing list