On Tue, 2019-01-15 at 17:02 +0000, Daniel P. Berrangé wrote: > On Tue, Jan 15, 2019 at 02:30:14PM +0100, Andrea Bolognani wrote: > > Basically VirtIO 0.9 requires IO space to be available, and 1.0 did > > away with that requirement because PCI Express, unlike conventional > > PCI, allows devices *not* to have IO space. > > > > So transitional devices, which must work with both 0.9 and 1.0, can > > depend on IO space being available and as such will only work when > > plugged into conventional PCI slots, whereas non-transitional > > devices don't need IO space and can thus be plugged into either > > conventional PCI and PCI Express slots. > > > > Ultimately, then, transitional (rather than non-transitional) > > devices are the ones that must be forced into conventional PCI > > slots. > > Yes, the existing devices fail when placed in a PCI-X slot with certain > guest OS. The -transitional devices are functionally identical to the > existing devices. They serve as a hint to libvirt that it should never > place them in a PCI-X slot. Not quite: existing devices (virtio-*-pci) will change their behavior based on the slot they're plugged into, so they will show up as non-transitional when connected to a PCI Express slot and as transitional otherwise. If that wasn't the case, there wouldn't have been a way to use VirtIO devices on x86/q35 or aarch64/virt without throwing pcie-to-pci-bridge into the mix until now, and we would also need to change the behavior for existing devices, neither of which is true :) Whether or not the guest OS supports VirtIO 1.0 and can thus drive a non-transitional device is a separate matter, which adding support for these new devices to libvirt and libosinfo will address. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
