On Sun, 2019-01-13 at 18:12 -0500, Cole Robinson wrote: [...] > The main RFC bits here are: > > * The disk approach. danpb and I briefly discussed on IRC adding > new bus= values vs a new model= attribute. We decided model= > is the lesser of two evils, since bus= handling in apps is > tied with target= generation, so adding new virtio-X bus= > values will cause more work for apps. These patches add > a <disk model=X/> attribute This sounds fairly reasonable, but I reserve the right to change my mind after looking at the code and thinking about it a bit more :) > * The XML and naming. Previous discussions seemed to favor adding > new model-style values rather than a 'transitional' attribute > or similar. So these patches add model='virtio-transitional' > and model='virtio-non-transitional' Yeah, that's what I recall the consensus being. > * The PCI address handling. I just mapped virtio-non-transitional > to imply plain PCI addressing. I think that's all we need but > I'm not positive so I'd appreciate a review of that approach. I don't think that's right. Let me fish up a message I wrote a while ago summing up interactions between VirtIO devices and PCI (Express) slots: http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg03133.html 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. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
