On Thu, 25 Jul 2019 at 14:43, Paolo Bonzini <pbonz...@redhat.com> wrote: > To me *maintainability is the biggest consideration* when introducing a > new feature. "We can do just as well with q35" is a good reason to > deprecate and delete microvm, but not a good reason to reject it now as > long as microvm is good enough in terms of maintainability.
I think maintainability matters, but also important is "are we going in the right direction in the first place?". virtio-mmio is (variously deliberately and accidentally) quite a long way behind virtio-pci, and certain kinds of things (hotplug, extensibility beyond a certain number of endpoints) are not going to be possible (either ever, or without a lot of extra design and implementation work to reimplement stuff we have already today with PCI). Are we sure we're not going to end up with a stream of "oh, now we need to implement X for virtio-mmio (that virtio-pci already has)", "users want Y now (that virtio-pci already has)", etc? The other thing is that once we've introduced something we're stuck with whatever it does, because we don't like breaking backwards compatibility. So I think getting the virtio-legacy vs virtio-1 story sorted out before we land microvm is important, at least to the point where we know we haven't backed ourselves into a corner or required a lot of extra effort on transitional-device support that we could have avoided. Which isn't to say that I'm against the microvm approach; just that I'd like us to consider and make a decision on these issues before landing it, rather than just saying "the patches in themselves look good, let's merge it". thanks -- PMM
