[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: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC v3 0/3] scsi: restart dma after vm change state handlers |
Date: |
Thu, 30 May 2019 00:10:30 +0200 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
Am 24.05.2019 um 20:47 hat Paolo Bonzini geschrieben:
> 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.
I don't think this is as nice because stopping or resuming a device
could involve some async operation (e.g. be delegated to a BH). In this
case, a device on a child bus must still wait for the BH (or other async
part) to be completed before it can resume its own operation.
Basically, a single flat list of global VM state handlers wasn't a good
design, because what we actually need in such cases is something
hierarchical.
Kevin