While doing some disruptive testing with QEMU/KVM, I have encountered some
guest problems during hot unplug of virtio-scsi devices depending on the
order of operations in which they are performed.  The following notes
describe my setup (s390x), and how I'm able to reproduce the error and
test the attached fix.

In both the "working" and "failing" case, the detaches appear to work
just fine.  Any sign of problems only begin to appear later based on
other actions I may perform, such as powering off the guest system.

Host:
 # lsscsi -g | grep sg6
 [6:0:6:1074151456]disk    IBM      2107900          .217  /dev/sdg   /dev/sg6 

QEMU:
 - Include the following parameters
    -device virtio-scsi-ccw,id=scsi0
    -drive file=/dev/sg6,if=none,id=drive0,format=raw
    -device 
scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive0,id=hostdev6
 - QMP commands (working)
    - device_del hostdev6
    - device_del scsi0
 - QMP commands (failing)
    - device_del scsi0

Libvirt:
 - Note: A preventative fix went into Libvirt 2.5.0
   (libvirt commit 655429a0d4a5 ("qemu: Prevent detaching SCSI controller used 
by hostdev"))
 - Include the following XML
    # cat scsicontroller.xml 
        <controller type='scsi' model='virtio-scsi' index='0'/>
    # cat scsihostdev.xml 
        <hostdev mode='subsystem' type='scsi'>
          <source>
            <adapter name='scsi_host6'/>
            <address bus='0' target='6' unit='1074151456'/>
          </source>
        </hostdev>
 - virsh commands (working)
    - virsh detach-device guest scsihostdev.xml
    - virsh detach-device guest scsicontroller.xml
 - virsh commands (failing)
    - virsh detach-device guest scsicontroller.xml

v1->v2:
 - Hold vq_lock across virtscsi_complete_cmd call (Fam Zheng)

Eric Farman (1):
  virtio_scsi: Reject commands when virtqueue is broken

 drivers/scsi/virtio_scsi.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to