[kata-dev] govmm/Kata integration, revisited

Christophe de Dinechin cdupontd at redhat.com
Fri Sep 3 11:25:39 UTC 2021



> On 3 Sep 2021, at 07:04, David Gibson <kata-dev at gibson.dropbear.id.au> wrote:
> 
> On Thu, Sep 02, 2021 at 05:52:38PM +0200, Christophe de Dinechin wrote:
>> 
>> 
>>> On 1 Sep 2021, at 12:05, David Gibson <kata-dev at gibson.dropbear.id.au> wrote:
>>> 
>>> On Wed, Sep 01, 2021 at 11:43:59AM +0200, Christophe de Dinechin wrote:
>>>> [resend with cut quote, original was held in moderation for being > 40K]
>>>> 
>>>>> On 31 Aug 2021, at 12:31, David Gibson <kata-dev at gibson.dropbear.id.au> wrote:
>>>>> 
>>>>> On Tue, Aug 31, 2021 at 09:23:04AM +0200, Fabiano Fidêncio wrote:
>>>>>> On Tue, Aug 31, 2021 at 5:16 AM David Gibson
>>>>>> <kata-dev at gibson.dropbear.id.au> wrote:
>>>>>>> 
>>>>>>> On Mon, Aug 30, 2021 at 01:24:20PM +0200, Fabiano Fidêncio wrote:
>>>>>>>> David,
>>>>>>>> 
>>>>> 
>>>>>> Then we will have an one not small patch removing the govmm vendor.
>>>>> 
>>>>> So, I'd be happy enough with this approach if we could incrementally
>>>>> introduce the new interface then drop govmm once the new interface
>>>>> covers everything.
>>>>> 
>>>>> Unfortunately, that doesn't really work, because govmm owns the qmp
>>>>> interface and the qemu command line, so we can't build a new interface
>>>>> "bottom up".
>>>> 
>>>> While we are at it, should we rename "govmm" to something that indicates
>>>> it's really specific to qemu?
>>> 
>>> Fwiw, my draft PR simply calls it the "qemu" package in the imported copy.
>>> 
>>>> Or do we want to take the opposite route
>>>> (which was evoked yesterday) to move to VMM the "hypervisor" abstraction
>>>> that we have in Kata?
>>> 
>>> I'm not really sure what you're suggesting here.
>> 
>> If govmm is a bad hypervisor abstraction, but we have a slightly better one in Kata
>> (i.e. hypervisor.go and the various hypervisor back-ends), then maybe we should
>> rather turn govmm into the hypervisor abstraction it was supposed to
>> be.
> 
> hypervisor.go is a better hypervisor abstraction *for the purpose*.
> Which is specifically to suit Kata's needs.  It's not a viable
> hypervisor abstraction for anyone else.

Most likely true.

> 
>> But that's clearly more complicated.
> 
> I think that's underselling it.  Making a general purpose hypervisor
> abstraction is an immensely difficult problem.  I know I sound like
> a broken record here, but that's been libvirt's entire thing for a
> decade, and they've at best partially succeeded.
> 
> Making an general purpose interface purely for qemu is much more
> practical.. but I still think it's more than the Kata project has
> spare capacity to take on.  And, in this case, it's not very clear
> exactly what you're abstracting.

I agree. I was not advocating this approach, but pointing out that
the possibility exists. "Clearly more complicated" was intended to
implicitly convey the points you made (and others).

> 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au <http://gibson.dropbear.id.au/>	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson <http://www.ozlabs.org/~dgibson>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210903/214a7741/attachment-0001.htm>


More information about the kata-dev mailing list