[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
Michael S. Tsirkin
Re: [Qemu-devel] [RFC v3 0/3] scsi: restart dma after vm change state handlers
Fri, 24 May 2019 15:08:00 -0400
On Fri, May 24, 2019 at 08:47:18PM +0200, Paolo Bonzini wrote:
> 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?)
Yes I think it's a good idea to explicitly say I don't care
about the order like this.
> VMSTATECHANGE_PRIO_IOTHREAD = 100
> VMSTATECHANGE_PRIO_DEVICE = 200
> where higher priorities run first on stop and last on resume.