Re: [PATCH RFC 0/8] qemu: allow disabling certain virtio revisions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/29/2016 09:37 AM, Ján Tomko wrote:
For https://bugzilla.redhat.com/show_bug.cgi?id=1227354

some users might want to adjust the QEMU defaults and disable
either virtio 0.9 or virtio 1.0 (spelled out as disable-legacy
and disable-modern on qemu command line).

This series uses a separate <virtio revision="x"> element
right under the relevant device element for consistency,
even though it might fit better in different subelemets for
some of them.

Ján Tomko (8):
   Fix indentation
   Add virtio revision attribute to memballoon
   Add virtio revision attribute to disks
   Add virtio revision attribute to controllers
   Add virtio revision attribute to filesystems
   Add virtio revision attribute to intefaces
   Add virtio revision to rng devices
   qemu: format options for enforcing virtio revisions

1) I don't see anything in this series checking that the qemu binary recognizes the disable-legacy or disable-binary options for any of the devices. I don't know if both options were added to all devices in the same release (so that there could be a single capability flag) or if they were added at different times (requiring multiple capability flags).

2) To assure that the actual device presented to the guest doesn't change in the future when defaults are changed, we may want to autofill "version" even when none is specified. (We would of course be stuck with the unfortunate problem of what to do with existing configs)

3) Although there are curently only 2 versions, it may end up in the future that we want to specify something like "minVersion='1.0'" without giving a "maxVersion" (this would be useful in a template config to suppress IO port usage by the device without locking to a specific virtio version). Of course, it's possible that virtio 1.0 is perfect, and we'll never need another version :-) (seriously, since we'd *want* to lock down to a specific version as soon as the template config became a real config, I guess we can just have a version attribute now, and easily add (min|maxVersion) in the future if/when there is a virtio 2.0)



  docs/formatdomain.html.in                          |  51 ++++++++++
  docs/schemas/domaincommon.rng                      |  29 ++++++
  src/conf/domain_conf.c                             |  72 +++++++++++++-
  src/conf/domain_conf.h                             |  14 +++
  src/qemu/qemu_command.c                            |  31 ++++++
  .../qemuxml2argv-virtio-revision.args              |  58 +++++++++++
  .../qemuxml2argv-virtio-revision.xml               | 107 +++++++++++++++++++++
  tests/qemuxml2argvtest.c                           |  10 ++
  .../qemuxml2xmlout-virtio-revision.xml             | 107 +++++++++++++++++++++
  tests/qemuxml2xmltest.c                            |   2 +
  10 files changed, 480 insertions(+), 1 deletion(-)
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.args
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.xml
  create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-revision.xml


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]