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
