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 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 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. Paolo > However, for whatever it's worth, if I have two or more luns > on a virtio-scsi adapter, the spurious REPORT_LUNS processing > (virtio_scsi_handle_cmd_req_prepare() call) occurs only when > I hotunplug a lun while the other luns are still plugged in, > until the last lun is unplugged. I do not see the spurious call to > virtio_scsi_handle_cmd_req_prepare() when the last lun is unplugged, > whether that was the only lun present, or if it was the last of many. > > Venu >
