On 3 Sep 2021, at 07:04, David Gibson <kata-dev@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@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@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@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 | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson