On 08/01/19 01:58, Paolo Bonzini wrote: > On 30/07/19 18:06, Laszlo Ersek wrote: >> On 07/29/19 14:57, Sergio Lopez wrote: >>> Implement the modern (v2) personality, according to the VirtIO 1.0 >>> specification. >>> >>> Support for v2 among guests is not as widespread as it'd be >>> desirable. While the Linux driver has had it for a while, support is >>> missing, at least, from Tianocore EDK II, NetBSD and FreeBSD. >> >> That's right; not only are there no plans to implement virtio-mmio/1.0 >> for OVMF (to my knowledge), I'd even argue against such efforts. >> >> OVMF is a heavy-weight guest firmware, which I see entirely out of scope >> for "micro VMs". And so virtio-mmio/1.0 would seem like a needless & >> unwelcome complication, from the OVMF maintainership perspective. > > But given that, why not rip out virtio-mmio completely?
Virtio-mmio used to be necessary because "qemu-system-aarch64 -M virt" lacked a PCI host originally. (The relevant commit is 4ab29b8214cc, "arm: Add PCIe host bridge in virt machine", 2015-02-13; part of v2.3.0.) Indeed I don't expect anyone to use virtio-mmio nowadays, and removing it would simplify both our home-grown VIRTIO_DEVICE_PROTOCOL, and the virtio drivers. But it's extra work, not entirely risk-free (regressions), and I can't tell if someone out there still uses virtio-mmio (despite me thinking that would be unreasonable). I wouldn't like to see more work sunk into it either way :) Laszlo
