[Kata-hypervisor] Link to the Hypervisor Prototype

Paolo Bonzini pbonzini at redhat.com
Thu Jun 7 10:46:22 UTC 2018


On 06/06/2018 23:00, Anthony Liguori wrote:
> "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.

Indeed similar points were "vociferously" raised by yours truly. ;)

I think Manohar agreed that QEMU is already _somewhat_ modular and there
is lots of room for improvement.  If we approach the problem this way,
it's okay to have Intel's code as a guideline for what could be done,
similar to how qboot vs. SeaBIOS played out.

Another important point that we agreed, was that total repository SLOC
doesn't really count, what matters is a clear understanding of which
files are being compiled.  Also Google expressed a preference for
avoiding #ifdefs, and QEMU isn't that bad in this respect.

My suggestion was to handle the diff in a similar way as the realtime
kernel patch, working upstream on both tooling and modularity so that
the size can be reduced.

Paolo

> 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.



More information about the Kata-hypervisor mailing list