On Thu, Oct 18, 2018 at 12:25:12PM +0200, Andrea Bolognani wrote: > On Wed, 2018-10-17 at 12:01 -0300, Eduardo Habkost wrote: > > On Wed, Oct 17, 2018 at 12:43:02PM +0200, Andrea Bolognani wrote: > > > The proposal doesn't directly address the interaction between virtio > > > protocol version and slot type. [...] > > > > It does. See the interface names added to each device type. > > Sorry, I might be blind but I'm still not seeing it... I see a bunch > of *-pci devices and exactly zero *-pcie devices. See below. > > [...] > > The difference between the devices is not just the bus type: it > > is a different type of device with different behavior. Using the > > bus type to differentiate them would be misleading. > > I'm not arguing that we should use the bus type *only* to > differentiate them, but rather that we should *also* differentiate > them by bus type; failing to do so will mean that... > > > e.g. both modern and transitional virtio devices can be plugged > > to Conventional PCI buses, but they have different PCI IDs. > > ... even people who should be very familiar with the topic by now, > like you and me, will get it wrong from time to time, as Michael > helpfully pointed out ;) > > > I'm considering doing this in v2: > > > > * Remove the -0.9 device type, because nobody seems to need it > > * Add two device types: > > * virtio-1-blk-pci-non-transitional > > * virtio-1-blk-pci-transitional > > > > This way, we: > > * Include only the major version of the spec (so > > we don't require new device types for virtio 1.1, 1.2, etc), > > * Use terms that come from the Virtio spec itself, to avoid > > ambiguity. > > That's quite a mouthful :) > > Anyway, whether a device or not is transitional should go next to > the spec version rather than at the end: this will also help with > consistency because we will need -device and -ccw variants of all > these, no? > > Can we assume if and when virtio 2.0 comes around it will also have > both a pure variant and a transitional one which is compatible with > virtio 1.0? If so, I would suggest the names should be > > virtio-1-blk-pcie (1.x only, PCIe slot) > virtio-1-transitional-blk-pci (transitional, PCI slot) > virtio-1-transitional-blk-pcie (transitional, PCIe slot) > > [...] > > > At the same time, we should not fool ourselves into thinking it will > > > take less than *years* before applications such as virt-manager can > > > actually take advantage of the new devices without compromising their > > > support for old libvirt and QEMU versions too much. > > > > > > So if we're doing this to rectify some questionable design choices > > > with the goal of having a better situation in the long run, then by > > > all means we should go ahead; but if we think this will allow us to > > > run RHEL 6 on q35 in the short term, then our efforts are probably > > > misguided. > > > > Good point. You might be right about oVirt and OpenStack, but > > I'm assuming at least some applications (maybe KubeVirt?) don't > > care about supporting old libvirt/QEMU versions and won't have > > that problem. > > AFAIK oVirt and OpenStack have been bumping their requirements quite > aggressively with each subsequent release, so it might not take them > that much time to catch up; I was thinking more about applications > like virt-manager, gnome-boxes and libguestfs, which historically > have maintained compatibility with old libvirt/QEMU releases for the > longest time.
OpenStack isn't that aggressive - its min is libvirt 1.3.1 and QEMU 2.5.0 Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
