qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing


From: Paolo Bonzini
Subject: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
Date: Fri, 20 May 2011 17:03:31 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]