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

[Eduardo Habkost]

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