Re: [Qemu-devel] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Jul 22, 2015 at 01:40:25PM +0200, Paolo Bonzini wrote:
> 
> 
> On 22/07/2015 12:19, Michael S. Tsirkin wrote:
> > > > SCSI passthrough was no longer supported in virtio 1.0, so this patch
> > > > fail the get_features() when both 1.0 and scsi is set. And also only
> > > > advertise VIRTIO_BLK_F_SCSI for legacy virtio-blk device.
> > > 
> > > Why is SCSI passthrough support not available in virtio 1.0 ? This
> > > will cause a regression for any users of that as & when QEMU changes
> > > to use virtio 1.0 by default. Can we not fix this regression instead.
> >
> > If we wanted to, we might be able to fix this but not for 2.4: we'd have
> > to extend the spec and guest drivers, in some way TBD.
> > 
> > Paolo would be best placed to answer whether this feature is desirable
> > in the future, I think the argument made when the spec was written was that
> > the feature is not widely used, and virtio scsi is available as
> > a replacement for people who need it.
> 
> No, the feature is not desirable in the future. There is no reason
> really not to use virtio-scsi passthrough instead, since virtio-scsi has
> been out for about 3 years now and is stable.
> 
> In addition, the implementation would either not be compatible with
> virtio 0.9, or would be different from everything else in the spec
> because it requires a particular framing for the buffers.

IIUC, the SCSI passthrough feature for virtio-blk is enabled by
setting the 'scsi=on' property on the virtio-blk device, which is
exposed by libvirt with XML:

    <disk type='block' device='lun'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/sda'/>
      <target dev='vda' bus='virtio'/>
    </disk>

(For use with virtio-scsi you'd just change the <target> element)

So if the guest is using virtio-1.0, then this will now fail to boot, or
cause an error from monitor hotplug. This is not too bad, but I'm just
wondering if there's anything else we ought to think about doing in libvirt
in this situation. Normally we'd try to detect unsupported things upfront
so we can report VIR_ERR_CONFIG_UNSUPPORTED, instead of the generic error
code VIR_ERR_INTERNAL_ERROR, but perhaps this is sufficiently niche to
not worry about it and its fine to just delegate error reporting to QEMU ?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|