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

[Cole Robinson]

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