On Wed, Feb 06, 2019 at 12:14:36PM -0500, Cole Robinson wrote: > 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. I just found this message on my inbox, sorry for missing it. Predicting the future is hard, and predicting the decisions of every downstream packagers of QEMU is harder. But I don't expect anybody to compile out just a few of the (-non)-transitional devices. This unlikely scenario doesn't seem worth the extra complexity of a large set of new capability flags. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
