vio-vscsi: Support multiple channels / buses

The spapr-vscsi device of QEMU supports multiple channels (a.k.a. buses).
But when QEMU is started with a device on a bus > 0, SLOF fails to detect
the device, so that the boot fails. For example:

 qemu-system-ppc64 -nodefaults  -nographic -serial stdio -device spapr-vscsi \
  -blockdev driver=file,filename=/path/to/cdrom.iso,node-name=d1,read-only=on \
  -device scsi-cd,id=cd1,drive=d1,channel=6,scsi-id=5,lun=1

Thus SLOF should scan the various channels for bootable SCSI devices, too.
Since the common SLOF code for scanning SCSI devices has no meaning of
"channels" or "bus", we simply fake the bus ID to be part of the target
ID, so instead of supporting 64 targets = 64 devices, we now support
8 channel * 64 targets = 512 devices instead.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1663160
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 board-qemu/slof/vio-vscsi.fs | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

On 10/01/2019 04:05, Thomas Huth wrote:
> The spapr-vscsi device of QEMU supports multiple channels (a.k.a. buses).


What about virtio-scsi?


> But when QEMU is started with a device on a bus > 0, SLOF fails to detect
> the device, so that the boot fails. For example:
> 
>  qemu-system-ppc64 -nodefaults  -nographic -serial stdio -device spapr-vscsi \
>   -blockdev driver=file,filename=/path/to/cdrom.iso,node-name=d1,read-only=on \
>   -device scsi-cd,id=cd1,drive=d1,channel=6,scsi-id=5,lun=1
> 
> Thus SLOF should scan the various channels for bootable SCSI devices, too.
> Since the common SLOF code for scanning SCSI devices has no meaning of
> "channels" or "bus", we simply fake the bus ID to be part of the target
> ID, so instead of supporting 64 targets = 64 devices, we now support
> 8 channel * 64 targets = 512 devices instead.
> 
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1663160
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  board-qemu/slof/vio-vscsi.fs | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/board-qemu/slof/vio-vscsi.fs b/board-qemu/slof/vio-vscsi.fs
> index be11b69..9395148 100644
> --- a/board-qemu/slof/vio-vscsi.fs
> +++ b/board-qemu/slof/vio-vscsi.fs
> @@ -481,14 +481,19 @@ TRUE VALUE first-time-init?
>  \ SCSI scan at boot and child device support
>  \ -----------------------------------------------------------
>  
> -\ We use SRP luns of the form 8000 | (bus << 8) | (id << 5) | lun
> -\ in the top 16 bits of the 64-bit LUN
>  : (set-target)
>      to current-target
>  ;
>  
> -: dev-generate-srplun ( target lun -- )
> -    swap 8 << 8000 or or 30 <<
> +\ We use SRP luns of the form 8000 | (target << 8) | (bus << 5) | lun
> +\ in the top 16 bits of the 64-bit LUN (i.e. the "Logical unit addressing
> +\ method" in SAM5). Since the generic scsi-probe code of SLOF does not
> +\ really care about buses, we assume that the upper 3 bits of the "target"
> +\ value are the "bus" field.
> +: dev-generate-srplun ( bus+target lun -- srplun )
> +    swap dup 1 >> e0 and      ( lun bus+target bus )
> +    swap 3f and 8 <<          ( lun bus target )
> +    8000 or or or 30 <<
>  ;
>  
>  \ We obtain here a unit address on the stack, since our #address-cells
> @@ -508,8 +513,9 @@ TRUE VALUE first-time-init?
>  ;
>  
>  \ Report the amount of supported SCSI IDs - QEMU uses "max_target = 63"
> +\ and "max_channel = 7", we combine both to 64 * 8 = 512 devices
>  : dev-max-target ( -- #max-target )
> -    40
> +    200
>  ;
>  
>  " scsi-probe-helpers.fs" included
>

On 2019-01-10 00:59, Alexey Kardashevskiy wrote:
> 
> 
> On 10/01/2019 04:05, Thomas Huth wrote:
>> The spapr-vscsi device of QEMU supports multiple channels (a.k.a. buses).
> 
> 
> What about virtio-scsi?

While in hw/scsi/spapr_vscsi.c you can find ".max_channel = 7", virtio-scsi
in QEMU does not have these channels:

$ grep -r VIRTIO_SCSI_MAX_CHANNEL include hw
include/hw/virtio/virtio-scsi.h:#define VIRTIO_SCSI_MAX_CHANNEL 0
hw/scsi/virtio-scsi.c:    virtio_stw_p(vdev, &scsiconf->max_channel, VIRTIO_SCSI_MAX_CHANNEL);
hw/scsi/virtio-scsi.c:    .max_channel = VIRTIO_SCSI_MAX_CHANNEL,

And in the virtio spec:

"When used to address a target and logical unit, the only supported format for lun is: first byte set to 1,
second byte set to target, third and fourth byte representing a single level LUN structure, followed by four
zero bytes.

According to SAM5, "single level LUN" means no bus or channel or whatsoever.

 Thomas

On 10/01/2019 17:21, Thomas Huth wrote:
> On 2019-01-10 00:59, Alexey Kardashevskiy wrote:
>>
>>
>> On 10/01/2019 04:05, Thomas Huth wrote:
>>> The spapr-vscsi device of QEMU supports multiple channels (a.k.a. buses).
>>
>>
>> What about virtio-scsi?
> 
> While in hw/scsi/spapr_vscsi.c you can find ".max_channel = 7", virtio-scsi
> in QEMU does not have these channels:
> 
> $ grep -r VIRTIO_SCSI_MAX_CHANNEL include hw
> include/hw/virtio/virtio-scsi.h:#define VIRTIO_SCSI_MAX_CHANNEL 0
> hw/scsi/virtio-scsi.c:    virtio_stw_p(vdev, &scsiconf->max_channel, VIRTIO_SCSI_MAX_CHANNEL);
> hw/scsi/virtio-scsi.c:    .max_channel = VIRTIO_SCSI_MAX_CHANNEL,
> 
> And in the virtio spec:
> 
> "When used to address a target and logical unit, the only supported format for lun is: first byte set to 1,
> second byte set to target, third and fourth byte representing a single level LUN structure, followed by four
> zero bytes.
> 
> According to SAM5, "single level LUN" means no bus or channel or whatsoever.

Ah, cool. Thanks for the explanation and the fix.