On 2022-10-05 23:37:33 +0200, Paolo Bonzini wrote: > On 10/4/22 01:13, Venu Busireddy wrote: > > > 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." > > 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? > > In QEMU, all HBAs except for esp.c and lsi53c895a.c support autosense. As in > the comment below, 00b is the right value for virtio-scsi. > > The code to build the 0Ah (control) mode page would be in scsi-disk.c for > example. Nobody ever wrote it because the values mentioned in the comment > below (00b if HBA supports autosense and therefore calls scsi_req_get_sense; > 10b for HBAs with no autosense, typically very old emulated parallel-SCSI > hardware) are the ones that make the most sense and OSes will just assume > them. > > 00b is also the default UA_INTLCK_CTRL value, so the mode page is not needed > at all for virtio-scsi.
I do see that the Solaris driver does send the 0x1a command during the initialization, perhaps (?) seeking the value of UA_INTLCK_CTRL. Since QEMU currently does not support it, QEMU sends back a key/asc/ascq=0x05/0x24/0x00 response, indicating that 0x1a is an Illegal Request. I am assuming that the Solaris driver does not handle that response well (I still don't have access to the source code to verify that), confuses itself about the value of UA_INTLCK_CTRL, and hence does not handle the response to the REPORT_LUNS command correctly. Maybe the Solaris driver assumes that QEMU will retain the unit attention condition (UA_INTLCK_CTRL = 10b?), and will respond with a REPORTED_LUNS_CHANGED for a subsequent command? Based on your confirmation that we want to handle the REPORT_LUNS command as if UA_INTLCK_CTRL is set to 0, I will proceed with the assumption that the Solaris driver is at fault, and will work with the Solaris driver folks. In the meantime, as you suggested, I will post v4 with the bus unit attention mechanism implemented. We still need that. Venu
