summaryrefslogtreecommitdiff
path: root/hw/virtio-scsi.c
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2012-05-16 12:54:06 +0200
committerAnthony Liguori <aliguori@us.ibm.com>2012-05-21 15:40:50 -0500
commita6c5c84ae25bc68f22725f77d6d77c98af5c4f9e (patch)
tree9acacae57e71ad820796415d58c8329692279023 /hw/virtio-scsi.c
parent12c5674b846dccf1f80fb43b64606721e6f78976 (diff)
downloadqemu-a6c5c84ae25bc68f22725f77d6d77c98af5c4f9e.tar.gz
virtio-blk: always enable VIRTIO_BLK_F_SCSI
VIRTIO_BLK_F_SCSI is supposed to mean whether the host can *parse* SCSI requests, not *execute* them. You could run QEMU with scsi=on and a file-backed disk, and QEMU would fail all SCSI requests even though it advertises VIRTIO_BLK_F_SCSI. Because we need to do this to fix a migration compatibility problem related to how QEMU is invoked by management, we must do this unconditionally even on older machine types. This more or less assumes that no one ever invoked QEMU with scsi=off. Here is how testing goes: - old QEMU, scsi=on -> new QEMU, scsi=on - new QEMU, scsi=on -> old QEMU, scsi=on - old QEMU, scsi=off -> new QEMU, scsi=on - new QEMU, scsi=off -> old QEMU, scsi=on ok (new QEMU has VIRTIO_BLK_F_SCSI, adding host features is fine) - old QEMU, scsi=off -> new QEMU, scsi=off ok (new QEMU has VIRTIO_BLK_F_SCSI, adding host features is fine) - old QEMU, scsi=on -> new QEMU, scsi=off ok, bug fixed - new QEMU, scsi=on -> old QEMU, scsi=off doesn't work (same as: old QEMU, scsi=on -> old QEMU, scsi=off) - new QEMU, scsi=off -> old QEMU, scsi=off broken by the patch Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'hw/virtio-scsi.c')
0 files changed, 0 insertions, 0 deletions