On 2022-10-03 18:13:06 -0500, Venu Busireddy wrote: > On 2022-09-30 18:25:48 +0200, Paolo Bonzini wrote: > > On Fri, Sep 30, 2022 at 4:42 PM Venu Busireddy > > <venu.busire...@oracle.com> wrote: > > > > > Immediately after a hotunplug event, qemu (without any action from > > > > > the guest) processes a REPORT_LUNS command on the lun 0 of the device > > > > > (haven't figured out what causes this). > > > > > > > > There is only one call to virtio_scsi_handle_cmd_req_prepare and it > > > > takes the command from the guest, are you sure it is without any > > > > action from the guest? > > > > > > I am sure, based on what I am observing. I am running the scsitrace > > > (scsitrace -n vtioscsi -v) command on the Solaris guest, and I see no > > > output there. > > > > Do you have the sources to the driver and/or to the scsitrace dtrace > > I do not have access to the source code. I am working on gaining access. > > > script? Something must be putting the SCSI command in the queue. > > Perhaps the driver is doing so when it sees an event? And if it is > > bypassing the normal submission mechanism, the REPORT LUNS commands is > > hidden in scsitrac; that in turn retruns a unit attention and steals > > While SAM does say "if a REPORT LUNS command enters the enabled command > state, the device server shall process the REPORT LUNS command and shall > not report any unit attention condition;," it also says that the unit > attention condition will not be cleared if the UA_INTLCK_CTRL is set to > 10b or 11b in the "Control mode page." > > It doesn't appear to me that virtio-scsi supports "Control mode pages."
Just to clarify, I am referring the mode pages with page code 0x0a (and any subpage codes). > Does it? If it doesn't, is the expected handling of REPORT LUNS command > be same as the case of UA_INTLCK_CTRL being set to 00b? > > And while trying to understand this, and reading the code regarding > the handling of UA_INTLCK_CTRL, I ran across the following comment in > scsi_req_get_sense(): > > /* > * FIXME: clearing unit attention conditions upon autosense should be done > * only if the UA_INTLCK_CTRL field in the Control mode page is set to 00b > * (SAM-5, 5.14). > * > * We assume UA_INTLCK_CTRL to be 00b for HBAs that support autosense, and > * 10b for HBAs that do not support it (do not call scsi_req_get_sense). > * Here we handle unit attention clearing for UA_INTLCK_CTRL == 00b. > */ > > If virtio-scsi doesn't support "Control mode pages," why does the above > comment even say "assume UA_INTLCK_CTRL to be 00b" or address the case > of 10b? Also, other than the reference to it in the above comment, > UA_INTLCK_CTRL is not used anywhere else in the code. This comment > confused me. Is the comment just wrong, or am I missing something? I am > just trying to understand this better so that I am better prepared when > the client driver folks start asking me questions about the qemu support. > > Venu > > > it from the other commands such as TEST UNIT READY, but that's a guest > > driver bug. > > > > But QEMU cannot just return the unit attention twice. I would start > > with the patch to use the bus unit attention mechanism. It would be > > even better to have two unit tests that check the behavior prescribed > > by the standard: 1) UNIT ATTENTION from TEST UNIT READY immediately > > after a hotunplug notification; 2) no UNIT ATTENTION from REPORT LUNS > > and also no UNIT ATTENTION from a subsequent TEST UNIT READY command. > > Debugging the guest is a separate step.
