This is the second part of my SCSI work. The first is still pending and this one is incomplete, but I still would like to get opinions early enough because this design directly affects the UI.
This series is half of the work that is necessary to support multiple LUNs behind a target. The idea is to have two devices, "scsi-path" and "scsi-target", each of which provides both a SCSIDevice and a SCSIBus. I plan to do this work using VSCSI and then cut-an^Wapply it later to virtio-scsi. This way we can be reasonably sure that the approach will be usable in the Linux virtio-scsi drivers too. For an HBA like VSCSI or the upcoming virtio-scsi, which supports multiple paths, you can add to your HBA: - a scsi-path (id=1) which has two scsi-disks. Then the disks will be at path 1, target 0, LUN 0/1 - a scsi-path (id=1) which has two scsi-targets each with a scsi-disk. Then the disks will be at path 1, target 0/1, LUN 0 - a scsi-path (id=1) which has two scsi-targets each with two scsi-disk. Then the four disks will be at path 1, target 0/1, LUN 0/1 - two scsi-path (id=1) each with two scsi-targets each with two scsi-disk. Then the eight disks will be at path 1, target 0/1, LUN 0/1 - a scsi-target (id=0) which has two scsi-disks. Then the disks will be at path 0, target 0, LUN 0/1 - a scsi-target (id=0) with two scsi-disks and a scsi-path (id=1) each with two scsi-targets each with two scsi-disks. Then two disks will be at path 0, target 0, LUN 0/1; four more will be at path 1, target 0/1, LUN 0/1. For an HBA like lsi, which only supports one level, you can add to your HBA: - a scsi-target (id=0) which has two scsi-disks. Then the disks will be at path 0, target 0, LUN 0/1 - two scsi-targets (id=0/1) which has two scsi-disks. Then the disks will be at path 0, targets 0/1, LUN 0/1 - one scsi-target (id=0) which has two scsi-disks and one scsi-disk (id=1). Then two disks will be at path 0, target 0, LUN 0/1, the third will be at path 0, target 1, LUN 0. and so on. The patches do not provide the devices and relaying mechanism, but add plumbing for parsing complex LUNs such as those used by VSCSI. Patch 2 is useful on its own, because it fixes a mismatch in VSCSI's handling of OpenFirmware and Linux LUNs. It adds the main parsing code, and I'll probably resubmit it soon. Patch 5 adds the infrastructure that will be used by the simple LSI case. Patch 6 adds the infrastructure that will be used in the full case, and already kind-of attaches VSCSI to it. The other 3 are just complimentary. Ideas? Does the interface seem applicable to libvirt? Paolo Bonzini (6): scsi: ignore LUN field in the CDB scsi: support parsing of SAM logical unit numbers scsi-generic: allow customization of the lun scsi-disk: allow customization of the lun scsi: let a SCSIDevice have children devices scsi: add walking of hierarchical LUNs hw/esp.c | 4 +- hw/lsi53c895a.c | 2 +- hw/scsi-bus.c | 170 +++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/scsi-defs.h | 22 +++++++ hw/scsi-disk.c | 19 +++--- hw/scsi-generic.c | 41 +++++++++++-- hw/scsi.h | 17 +++++ hw/spapr_vscsi.c | 22 ++----- 8 files changed, 264 insertions(+), 33 deletions(-) -- 1.7.4.4
