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.
Thanks,
Cole
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
