qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] scsi: restart dma after vm change state handlers


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] scsi: restart dma after vm change state handlers
Date: Wed, 22 May 2019 11:48:09 +0100
User-agent: Mutt/1.11.4 (2019-03-13)

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]