On Wed, Sep 07, 2016 at 09:38:04PM +0200, Sascha Silbe wrote: > Dear Laine, > > Laine Stump <laine@xxxxxxxxx> writes: > > > On 09/07/2016 02:35 PM, Sascha Silbe wrote: > >> "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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), Legacy is a generic concept found in virtio 1 spec. Modern isn't, virtio 1 only has transitional/non-transitional. If you want to stick to the spec you should therefore use legacy/transitional/non-transitional at the API level. It is true that not all transports have all options. ccw does not support non-transitional devices, mmio does not support transitional ones. So in a quest to give users the most flexibility QEMU interface became messy as usual. Sorry about that :( > so > virtio-*-ccw devices don't recognise that switch: > > silbe@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@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). So the point is that qemu would typically do the right thing. So maybe for the model it makes sense to have legacy/transitional/non-transitional/auto and then translate it to whatever qemu flags are. > 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. Can be helpful as work-arounds for guest/host bugs as well. > > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list