[libvirt] [PATCH 0/6] RFC: qemu: virtio-{non-}transitional support

[Daniel P. Berrangé]

On Sun, Jan 13, 2019 at 06:12:02PM -0500, Cole Robinson wrote:
> This series adds the beginnings of support for virtio-transitional
> and virtio-non-transitional qemu devices.
> 
> qemu patches, queued for qemu 4.0.0:
> https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg00923.html
> Previous libvirt discussion around this:
> https://www.redhat.com/archives/libvir-list/2018-August/msg01073.html
> 
> Long story short we need to expose these options so apps have a
> usable way to support rhel6 + virtio + q35.
> 
> This series only covers exposing the associated device models
> for disk and rng devices to make sure I'm on the right track.
> serial, net, scsi, input-host, balloon 9p, vsock, vhost-scsi
> still need to be implemented. Those should follow the rng
> example, except vhost-scsi may need to be a different approach.

virDomainNetDef is a mess because it *still* doesn't use a enum
for the device model :-(   We really must fix that rather than
blindly allowing arbitrary passthrough of hypervisor specific
names.

I recall Laine had patches for this some 4/5 years ago, but
can't remember why we never merged them.

> The main RFC bits here are:
> 
> * The disk approach. danpb and I briefly discussed on IRC adding
>   new bus= values vs a new model= attribute. We decided model=
>   is the lesser of two evils, since bus= handling in apps is
>   tied with target= generation, so adding new virtio-X bus=
>   values will cause more work for apps. These patches add
>   a <disk model=X/> attribute

Yes, using 'bus' will have a very painful ripple effect on
mgmt apps we should avoid at all costs.

> * The XML and naming. Previous discussions seemed to favor adding
>   new model-style values rather than a 'transitional' attribute
>   or similar. So these patches add model='virtio-transitional'
>   and model='virtio-non-transitional'

Yep.

> * The PCI address handling. I just mapped virtio-non-transitional
>   to imply plain PCI addressing. I think that's all we need but
>   I'm not positive so I'd appreciate a review of that approach.

This was inverted, as Andrea already clarified

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|