[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v3 0/3] scsi: restart dma after vm change state ha
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC v3 0/3] scsi: restart dma after vm change state handlers |
Date: |
Thu, 30 May 2019 10:52:49 +0200 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
Am 30.05.2019 um 10:27 hat Paolo Bonzini geschrieben:
> On 30/05/19 00:10, Kevin Wolf wrote:
> > 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.
>
> So add an AioContext state change handler?
Does anything really change for the AioContext that could cause a
callback? As I read the code, only the virtio-scsi device state really
changes and it doesn't do more with the AioContext than just taking the
lock for a while.
But in any case, inferring whether the HBA is ready from some AioContext
state change, even if it were technically possible, is rather indirect
and more a hack than a proper solution in my book. So a callback from
the HBA to its bus feels like the correct approach.
Kevin