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

Laine Stump laine at laine.org
Mon Aug 1 14:02:10 UTC 2016


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
>




More information about the libvir-list mailing list