On Wed, Sep 07, 2016 at 09:38:04PM +0200, Sascha Silbe wrote:
> Dear Laine,
> 
> Laine Stump <la...@laine.org> writes:
> 
> > On 09/07/2016 02:35 PM, Sascha Silbe wrote:
> >> "Daniel P. Berrange" <berra...@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),

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

Reply via email to