[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v3 0/3] scsi: restart dma after vm change state ha
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC v3 0/3] scsi: restart dma after vm change state handlers |
Date: |
Fri, 24 May 2019 20:47:18 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
On 24/05/19 20:36, Stefan Hajnoczi wrote:
> v3:
> * Fix s/k->vmstate_change/vdc->vmstate_change/
> * Still RFC, waiting for customer to confirm this fixes the issue
> v2:
> * Do it properly with a clean API instead of deferring to a BH!
> Thanks for encouraging me to do this, Kevin.
>
> These patches solve a deadlock when the 'cont' command is used and there are
> failed requests on a virtio-scsi device with iothreads. The deadlock itself
> is
> actually not the thing we need to fix because we should never reach that case
> anyway. Instead we need to make sure DMA restart is only performed after the
> virtio-scsi iothread is re-initialized.
custom_dma_restart is a bit ugly... Do you think it would make sense to
order the VMStateChange handlers using some kind of enum (with the order
unspecified within the category)?
We could start with
VMSTATECHANGE_PRIO_UNKNOWN = 0 (if needed?)
VMSTATECHANGE_PRIO_IOTHREAD = 100
VMSTATECHANGE_PRIO_DEVICE = 200
where higher priorities run first on stop and last on resume.
Paolo