[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