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. > > Paolo
