On Tue, 25 Nov 2014 23:20:11 +0200 "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > On Tue, Nov 25, 2014 at 06:29:42PM +0100, Cornelia Huck wrote: > > On Tue, 25 Nov 2014 18:41:35 +0200 > > "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > > > > disable virtio 1.0 in transports that don't > > > support it yet. > > > > I'd prefer if you disabled it for _every_ transport in this patch, > > until the needed infrastructure is in place. Else this is a bit > > confusing. > > Well the only transports left are pci and rpoc, and these only > read the low 32 bit of the features from the device - > so there's nothing to clear. > > E.g. the following would be even more confusing, would it not: > > u32 features; > .... > features &= ~BIT_ULL(VIRTIO_F_VERSION_1); > > Agree? Maybe you should tweak the patch description a bit and mention that you only disable virtio 1.0 for transports where it is actually needed? (...) > > FWIW, as negotiating a revision >= 1 is a pre-req for virtio 1.0 > > support on ccw, virtio 1.0 is already implicitly disabled. > > Ah, you mean device guarantees that VIRTIO_F_VERSION_1 isn't set > if guest sets revision to 0? Yes, the bit will not be offered if the revision is 0 or has not been set at all. > In that case it's probably best to drop this from both ccw > devices. There's only one ccw transport :) The old s390 virtio transport in kvm_virtio.c is not part of virtio 1.0. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
