> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > On 04/05/2017 15:02, Pavel Dovgalyuk wrote: > >> Understood. And what checkpoint will you be waiting for during drain, > >> causing a deadlock? > > Every checkpoint processes the queue, but none of them are invoked, > > because iothread (which invokes all the checkpoints) is waiting for the end > > of the drain. > > > > And we cannot add a checkpoint into the drain, because then vmstop will > > affect the behavior of the guest. > > But it does affect the behavior already when RR is off. And it > shouldn't be a problem if it does in record mode (as long as the effect > can be replayed).
Then we'll have to add something like "stop" event which flushes the queue. And there is still a problem with stopping in replay mode, because there is no way to flush the queue, because coroutines are executing somewhere. > If RR cannot do drain reliably, not even in record mode, that is a huge > problem because a lot of block layer operations assume they can. I think it could be an acceptable limitation (like disabling savevm/loadvm when queue is not empty). I assume that RR is mostly used for debugging and analysis and it could have some limitations of this kind. Making our own block queue (instead of coroutines) is much worse, therefore we have to replay the original internal behavior. Pavel Dovgalyuk
