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 viablehypervisor abstraction for anyone else.
Most likely true.
But that's clearly more complicated.
I think that's underselling it. Making a general purpose hypervisorabstraction is an immensely difficult problem. I know I sound likea broken record here, but that's been libvirt's entire thing for adecade, and they've at best partially succeeded.Making an general purpose interface purely for qemu is much morepractical.. but I still think it's more than the Kata project hasspare capacity to take on. And, in this case, it's not very clearexactly 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).