Re: [PATCH v3] virtio-scsi: Send "REPORTED LUNS CHANGED" sense data upon disk hotplug events.

[Paolo Bonzini <pbonzini@redhat.com>]

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.

Paolo

> 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.
>