[Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
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
Re: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
On Fri, May 20, 2011 at 05:03:31PM +0200, Paolo Bonzini wrote: > 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 don't quite understand what you mean with path here. It doesn't seem to map to any SAM concept, nor does it seem to be related to traditional multipathing. Can you explain what a path is supposed to be, and why it's called a "path"?
Re: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
On 05/20/2011 06:14 PM, Christoph Hellwig wrote: I don't quite understand what you mean with path here. It doesn't seem to map to any SAM concept, nor does it seem to be related to traditional multipathing. It's what SAM calls a "bus identifier" in the description of LUN addressing modes. Can you explain what a path is supposed to be, and why it's called a "path"? It's a SAM "BUS IDENTIFIER", but bus was too confusing with respect to qdev's BusState (which represents either a SAM bus identifier or target). I think the term "path" comes from Windows, see for example http://msdn.microsoft.com/en-us/library/ff564699%28v=vs.85%29.aspx: PathId [in, optional] Indicates the SCSI port or bus for the request. This parameter is optional. ... but I chose it because I found it also in SAM: "The BUS IDENTIFIER field identifies the bus or path that the SCSI device shall use to relay the received command or task management function". I might also call it scsi-initiator which is consistent from the idea that it sits between two targets ports. Paolo
Re: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
On Fri, May 20, 2011 at 07:37:30PM +0200, Paolo Bonzini wrote: > On 05/20/2011 06:14 PM, Christoph Hellwig wrote: >> I don't quite understand what you mean with path here. It doesn't >> seem to map to any SAM concept, nor does it seem to be related >> to traditional multipathing. > > It's what SAM calls a "bus identifier" in the description of LUN addressing > modes. Ok, so it more or less translates to the concept of a "channel" in the Linux SCSI subsystem. It would help if you could explain the concept in a bit more detail in a comment. Or in fact not bother with it at all, which should be easy if we never present hierachial LUNs.
Re: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
On 05/25/2011 03:17 PM, Christoph Hellwig wrote: On Fri, May 20, 2011 at 07:37:30PM +0200, Paolo Bonzini wrote: On 05/20/2011 06:14 PM, Christoph Hellwig wrote: I don't quite understand what you mean with path here. It doesn't seem to map to any SAM concept, nor does it seem to be related to traditional multipathing. It's what SAM calls a "bus identifier" in the description of LUN addressing modes. Ok, so it more or less translates to the concept of a "channel" in the Linux SCSI subsystem. Yes. It would help if you could explain the concept in a bit more detail in a comment. Or in fact not bother with it at all, which should be easy if we never present hierachial LUNs. Unfortunately spapr_vscsi requires hierarchical LUNs. The OpenFirmware code starts by sending out INQUIRY messages to channel 0/1/2/3/4/5/6/7 target 0 LUN 0 (it doesn't recognize other targets or LUNs as far as I can see). So if you want to have a CD-ROM and a HD on your virtual machine, and you want your HD to keep its name both during the installation process and afterwards, you pretty much have to use channel 0 for the HD and another channel for the CD-ROM.. Paolo
