On Tue, May 21, 2019 at 01:30:59PM +0200, Kevin Wolf wrote: > Am 21.05.2019 um 13:04 hat Paolo Bonzini geschrieben: > > On 21/05/19 12:36, Stefan Hajnoczi wrote: > > > This is RFC because I am waiting for a test result on the system where > > > the bug was originally discovered. I'm also open to nicer solutions! > > > > I don't think it's too ugly; IDE is also using a bottom half for this. > > I think the IDE case is different, see commit 213189ab65d. The case > we're protecting against there is stopping the VM from inside a VM state > handler, which can confuse other VM state callbacks that come later. The > actual order of the IDE callback vs. the other callback doesn't matter, > it's just important that all start callbacks are completed before stop > callbacks are called. > > In our current case, the problem is not that we're confusing other > handlers, but that we rely on another handler to have completed resuming > something. If that other handler changes e.g. to use a BH itself, we get > an undefined order again. > > The clean solution would probably be not to use a VM state handler in > scsi-bus, but a callback from the HBA that tells the bus that the HBA is > ready to receive requests again. > > If we go with the not so clean solution, maybe at least a comment in > virtio-scsi would be in order.
I explored this approach originally but found it hard to connect things together in an easy-to-understand way. That's when I abandoned the idea and used a BH as a hack, but I find it problematic in the long-term (too many things could go wrong and cause a regression). Time for another look at a proper callback for DMA restart... Stefan
signature.asc
Description: PGP signature
