Re: [Qemu-block] [PATCH 2/2] virtio-scsi/virtio-blk: Disable poll handlers when stopping vq handler

[Paolo Bonzini]

On 13/09/2018 08:03, Fam Zheng wrote:
> On Wed, 09/12 14:42, Paolo Bonzini wrote:
>> On 12/09/2018 13:50, Fam Zheng wrote:
>>>> I think it's okay if it is invoked.  The sequence is first you stop the
>>>> vq, then you drain the BlockBackends, then you switch AioContext.  All
>>>> that matters is the outcome when virtio_scsi_dataplane_stop returns.
>>> Yes, but together with vIOMMU, it also effectively leads to a 
>>> virtio_error(),
>>> which is not clean. QEMU stderr when this call happens (with patch 1 but not
>>> this patch):
>>>
>>> 2018-09-12T11:48:10.193023Z qemu-system-x86_64: vtd_iommu_translate: 
>>> detected translation failure (dev=02:00:00, iova=0x0)
>>> 2018-09-12T11:48:10.193044Z qemu-system-x86_64: New fault is not recorded 
>>> due to compression of faults
>>> 2018-09-12T11:48:10.193061Z qemu-system-x86_64: virtio: zero sized buffers 
>>> are not allowed
>>
>> But with iothread, virtio_scsi_dataplane_stop runs in another thread
>> than the iothread; in that case you still have a race where the iothread
>> can process the vq before aio_disable_external and print the error.
>>
>> IIUC the guest has cleared the IOMMU page tables _before_ clearing the
>> DRIVER_OK bit in the status field.  Could this be a guest bug?
> 
> I'm not sure if it is a bug or not. I think what happens is the device is left
> enabled by Seabios, and then reset by kernel.

That makes sense, though I'm not sure why QEMU needs to process a
request long after SeaBIOS has left control to Linux.  Maybe it's just
that the messages should not go on QEMU stderr, and rather trace-point
should be enough.

Paolo