Re: vioscsi cmd target id

[christos%astron.com@localhost (Christos Zoulas)]

In article <CAAw6btkQ34JoUNjt-Vht0aKVe=hAVpTwy5K7iDm5ycb6Pza2Ng%mail.gmail.com@localhost>,
Rohan Desai  <desai.p.rohan%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>Having an issue with vioscsi in GCE. vioscsi decrements the target id in
>commands it sends to virtio. This means that the upper layers notion of the
>target id is off by 1. This is especially problematic when presented a lun
>on the last target of a bus. It never gets discovered because the scsipi
>probe code sends down an xs with the last target number, which vioscsi then
>decrements in the command it sends along. The probe code never moves on to
>the next target (since it thinks its probed all the targets on the bus) and
>the lun is never discovered. I hit this in GCE for local disks because they
>create a new bus with a single target for each local disk.
>
>Here's a patch that fixes the issue for me:
>
>@@ -279,12 +279,12 @@ vioscsi_scsipi_request(struct scsipi_channel *chan,
>scsipi_adapter_req_t
>                goto stuffup;
>        }
>        req->lun[0] = 1;
>-       req->lun[1] = periph->periph_target - 1;
>+       req->lun[1] = periph->periph_target;
>        req->lun[2] = 0x40 | (periph->periph_lun >> 8);
>        req->lun[3] = periph->periph_lun;
>        memset(req->lun + 4, 0, 4);
>        DPRINTF(("%s: command for %u:%u at slot %d\n", __func__,
>-           periph->periph_target - 1, periph->periph_lun, slot));
>+           periph->periph_target, periph->periph_lun, slot));
>
>        if ((size_t)xs->cmdlen > sizeof(req->cdb)) {
>                DPRINTF(("%s: bad cmdlen %zu > %zu\n", __func__,
>
>Any reason for decrementing periph_target in the first place?

Yes, somehow the first target presented to me was unusable. I tried it with
qemu..
https://wiki.netbsd.org/tutorials/how_to_setup_virtio_scsi_with_qemu/

christos