On Wed, Jul 03, 2019 at 12:04:00AM +0200, Sergio Lopez wrote: > On Tue, Jul 02, 2019 at 07:04:15PM +0100, Peter Maydell wrote: > > On Tue, 2 Jul 2019 at 18:34, Sergio Lopez <s...@redhat.com> wrote: > > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > > Could we use virtio-pci instead of virtio-mmio? virtio-mmio is > > > > a bit deprecated and tends not to support all the features that > > > > virtio-pci does. It was introduced mostly as a stopgap while we > > > > didn't have pci support in the aarch64 virt machine, and remains > > > > for legacy "we don't like to break existing working setups" rather > > > > than as a recommended config for new systems. > > > > > > Using virtio-pci implies keeping PCI and ACPI support, defeating a > > > significant part of microvm's purpose. > > > > > > What are the issues with the current state of virtio-mmio? Is there a > > > way I can help to improve the situation? > > > > Off the top of my head: > > * limitations on numbers of devices > > * no hotplug support > > * unlike PCI, it's not probeable, so you have to tell the > > guest where all the transports are using device tree or > > some similar mechanism > > * you need one IRQ line per transport, which restricts how > > many you can have > > * it's only virtio-0.9, it doesn't support any of the new > > virtio-1.0 functionality > > * it is broadly not really maintained in QEMU (and I think > > not really in the kernel either? not sure), because we'd > > rather not have to maintain two mechanisms for doing virtio > > when virtio-pci is clearly better than virtio-mmio > > Some of these are design issues, but others can be improved with a bit > of work. > > As for the maintenance burden, I volunteer myself to help with that, so > it won't have an impact on other developers and/or projects. > > Sergio.
OK so please start with adding virtio 1 support. Guest bits have been ready for years now. -- MST
