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