bhyve/virtio-scsi: Implement task management functions

[rosenfeld_grumpf.hope-2000.org]

Summary

Currently, all I/O requests are queued internally, and a number of
threads will pick I/O requests of the queue and send them to CTL with
a synchronous CTL_IO ioctl. On the other hand, TMF requests are sent
to CTL immediately using the same synchronous ioctl.

Besides being unworkable for non-CTL backends such as for SCSI
passthrough, this simple approach may easily run into situations
where a TMF request operating on a particular I/O request is sent
to CTL while it is still on our queue and thus unknown to CTL.
In addition, for target and/or LUN resets we should really clear
our queue and return all outstanding I/O requests with a proper
status.

This is currently also under review in illumos: https://code.illumos.org/c/illumos-gate/+/4424

[rosenfeld_grumpf.hope-2000.org]

Rebase.

[rosenfeld_grumpf.hope-2000.org]

Rebase.

[rosenfeld_grumpf.hope-2000.org]

Reword comment in pci_vtscsi_tmf_handle().

[rosenfeld_grumpf.hope-2000.org]

Rebase.

[rosenfeld_grumpf.hope-2000.org]

Rebase.

[markj]

usr.sbin/bhyve/pci_virtio_scsi.c

718

Is it possible this will return false negatives if the task is actively being processed by a worker thread? In that case the corresponding request won't be on a queue anymore, so this search won't find it.

782

[markj]

The commit log message should also briefly explain what's actually changing in the patch.

[rosenfeld_grumpf.hope-2000.org]

Review from markj.

[rosenfeld_grumpf.hope-2000.org]

usr.sbin/bhyve/pci_virtio_scsi.c

718

Yes, there is a slim chance of a race between a I/O worker thread and the TMF handling. If a thread handingling a TMF request locks the queue just after a worker thread has taken an I/O request off the queue, then there is a chance the TMF code calls the CTL ioctl() before the I/O worker thread has done so. In that case, the TMF request won't see this I/O request, neither when being processed in CTL nor when the TMF code scans the queue. If that happens to also be the the I/O request the TMF request is supposed to act on, it'll cause a false negative.

I think there's very little we can do about it. The CTL ioctl() is handled synchronously, and since we can't know when it has processed in CTL to a point that a TMF request sent to CTL will find it, all we could do is wait for its completion, which kinda defeats the purpose of sending the TMF request to CTL in the first place.

On the other hand, if I read the T10 specs correctly, a false negative on these requests isn't really much of a problem, and I think the chance of that even happening is quite slim, too.