On 1/29/19 11:05 AM, Andrea Bolognani wrote:
On Tue, 2019-01-29 at 15:48 +0100, Ján Tomko wrote:
On Wed, Jan 23, 2019 at 04:32:38PM -0500, Cole Robinson wrote:
This adds QEMU_CAPS flags for the following devices
virtio-blk-pci-transitional virtio-blk-pci-non-transitional virtio-net-pci-transitional virtio-net-pci-non-transitional vhost-scsi-pci-transitional vhost-scsi-pci-non-transitional virtio-rng-pci-transitional virtio-rng-pci-non-transitional virtio-9p-pci-transitional virtio-9p-pci-non-transitional virtio-balloon-pci-transitional virtio-balloon-pci-non-transitional vhost-vsock-pci-transitional vhost-vsock-pci-non-transitional virtio-input-host-pci-transitional virtio-input-host-pci-non-transitional virtio-scsi-pci-transitional virtio-scsi-pci-non-transitional virtio-serial-pci-transitional virtio-serial-pci-non-transitional
This seems excessive, is there a plan to retire the transitional devices? I don't expect anyone creating a QEMU build that e.g.: a) supports virtio-rng-pci-transitional but not virtio-rng-pci-non-transitional b) supports virtio-scsi-pci-transitional but not virtio-input-host-pci-transitional
For the disable-legacy property, we only have QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY, that is checked on multiple (but not all possible) PCI devices.
That's a very good point! We could have a single capability
QEMU_CAPS_VIRTIO_PCI_NON_TRANSITIONAL
that is set if any out of a bunch of {,non-}transitional devices is present, and key everything else off that...
Eduardo, do you think we might ever get in trouble if we did that? For example, because of QEMU dropping transitional devices but leaving non-transitional devices in?
I believe eduardo is offline for the next few weeks, so I'll make this change in the next version to just track a single capability QEMU_CAPS_VIRTIO_PCI_NON_TRANSITIONAL We can always add the fine grained capabilities later if needed. Thanks, Cole