On Wed, Jul 15, 2020 at 06:32:28PM +0100, Alex Bennée wrote:
Hi,
Looking at the history of VirtIO is seems very much like virtio-mmio is treated as the legacy interface with most of the action to date being directed at virtio-pci which has a number of advantages including:
- already specified behaviour and driver model
- enumeration support
- support for MSI signals
The benefits of this have even led to specs for alternative transport/devices such and IVSHMEMv2 being based around a PCI device model.
There are detractors however, most notably the new microvm machine types have chosen virtio-mmio's static assignment because it allows for a faster spin up of VMs as you don't need to deal with specified settle times in the spec.
Azzedine mentioned in a previous call that the PCI device model adds complications based on assumptions about real HW which might not be relevant to virtual devices. Others have mentioned the increased complexity of the code base to handle a full PCI device.
I'm curious to what the implications are for supporting PCI in type-1 hypervisors? Is the desire to avoid handling all the details of PCI within the small hypervisor code base and punt details to the Dom0 causing more vmexits?
As Srivatsa mentioned there have been some attempts to update the virtio-mmio spec to support MSI IRQs which I think are the best way to minimise unwanted context switches. So should we raise a card to help with that effort?
Work that would be involved:
- defining the out-of-band information (MSI irqs in device tree?)
I think you'd only need to add an msi-parent property to the virtio-mmio node, the rest should be configurable through virtio config space.
- updating the spec
- supporting MSI in the virtio-mmio front-end
Anything else?
Of course one worry would be that by adding all this additional functionality to virtio-mmio you start to approach the complexity of virtio-pci.
That was one concern on the latest proposal (Feb 2020), that adding features such as MSI to virtio-mmio could make it as complex as virtio-pci, without the advantage of sharing core code with other device drivers. https://lwn.net/ml/linux-kernel/20200211053953-mutt-send-email-mst@kernel.or...
We have been using MMIO given its simplicity and also want the performance improvements offered by the proposed MSI extensions. I don't see the need for other fancy features like hotplug/error_reporting infrastructure that PCI provides, so I feel MMIO + MSI is still a useful and simpler option to provide for platform designers. We would support any efforts to make this possible upstream.
Implementing even a basic conventional PCI device is more complicated than an MMIO device, but then adding features (MSI, hotplug, virtual functions, PASID, etc) becomes a lot simpler since they are already standardized and supported by guests.
Thanks, Jean
I don't know if this is a real worry but I suspect people using virtio-mmio for speed won't want any optional enhancements to slow it down.