[libvirt] [PATCHv5 00/13] qemu: allow disabling certain virtio revisions

Sascha Silbe silbe at linux.vnet.ibm.com
Wed Sep 7 19:38:04 UTC 2016


Dear Laine,

Laine Stump <laine at laine.org> writes:

> On 09/07/2016 02:35 PM, Sascha Silbe wrote:
>> "Daniel P. Berrange" <berrange at redhat.com> writes:
>> [...]
>>>       <sound model="virtio"/>     == QEMU virtio
>>>       <sound model="virtio1.0"/>  == QEMU virtio + disable-legacy
>> What would this do for devices using the virtio-ccw transport?
>
>  From libvirt's point of view, the option "disable-legacy=on" would be 
> added to the device's commandline argument.

Which would break s390x guests. virtio-ccw doesn't have any concept of
"legacy" or "modern" devices (that's purely a virtio-pci concept), so
virtio-*-ccw devices don't recognise that switch:

silbe at oc4731375738:~$ ~/build/qemu-devel/x86_64-softmmu/qemu-system-x86_64 -device virtio-blk,help 2>&1 |grep legacy
virtio-blk-pci.disable-legacy=OnOffAuto (on/off/auto)
silbe at oc4731375738:~$ ~/build/qemu-devel/s390x-softmmu/qemu-system-s390x -device virtio-blk,help 2>&1 |grep legacy

That nicely illustrates the issue I have with a) mixing virtio-pci
legacy/modern into the model name and b) conflating it with virtio
0.9/1.0 (or transitional/non-transitional for that matter).

FWIW, the thing closest to virtio-pci legacy/modern is virtio-ccw
max_revision. But I doubt there's any reason to set this beyond
debugging and testing.


> For the effect, you would 
> need to ask a qemu virtio person, or even better - a qemu s390 person 
> who knows something about about virtio. I Cc'ed Michael (the former) and 
> Cornelia Huck (the latter, according to this patch I found: 
> https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01024.html )

Thanks, but I'm working on qemu for s390x myself. :)

Sascha
-- 
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr. DE281696641





More information about the libvir-list mailing list