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