Re: [libvirt] [PATCH v2 10/25] qemu: capabilities: Add virtio/vhost {non-}transitional

On 2/6/19 11:54 AM, Andrea Bolognani wrote: > On Wed, 2019-02-06 at 11:12 -0500, Cole Robinson wrote: > > On 1/29/19 11:05 AM, Andrea Bolognani wrote: > > > 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. > > Sounds good, let's just make sure he has a chance to veto the > approach *before* it ends up in a stable libvirt release, to avoid > compatibility headaches in case we were wrong O:-) > If there's a chance I'm going to have redo the series and edit every qemu_command.c patch again to use the fine grained capabilities, then I'll just wait for his response. But I don't really think it's necessary. Presumably if -transitional or -non-transitional devices are compiled out of qemu, the equivalent disable-legacy/disable-modern config should be rejected too. So if our qemuCaps detection is wrong, and we determine -transitional/-non-transitional is supported when it is actually compiled out, the user request is never going to work anyways. So even if eduardo suggests using the fine grained capabilities, we could do it as a follow on patch. The one place it may actually matter is in domaincapabilities; we don't want to incorrectly report that virtio-transitional is supported for a device, because apps may make programmatic decisions based on what we report. So we could defer the disk domaincapabilities patch until we get a clear answer. FWIW that was my original motivation for going fine grained with the qemuCaps values, I expect to eventually expose all of them in domaincapabilities.