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
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

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

Reply via email to