On Mon, Jun 17, 2019 at 08:27:04PM +0200, Paolo Bonzini wrote:
> On 17/06/19 19:58, Kevin Wolf wrote:
> > Of course, this makes me think that maybe for the actual proper
> > solution, VM state change handlers should really be a feature that qdev
> > provides for devices. Then if a HBA doesn't have
On 17/06/19 19:58, Kevin Wolf wrote:
> Of course, this makes me think that maybe for the actual proper
> solution, VM state change handlers should really be a feature that qdev
> provides for devices. Then if a HBA doesn't have anything else to do,
> the qdev core would just recurse into the childr
Am 17.06.2019 um 19:23 hat Paolo Bonzini geschrieben:
> On 17/06/19 14:29, Kevin Wolf wrote:
> > But in the end, if Paolo feels strongly that for whatever reason
> > propagating events through the real device tree isn't good, let's get
> > the bug fixed with whatever hack it takes.
>
> It is actua
On 17/06/19 14:29, Kevin Wolf wrote:
> But in the end, if Paolo feels strongly that for whatever reason
> propagating events through the real device tree isn't good, let's get
> the bug fixed with whatever hack it takes.
It is actually good, but the implementation in hw/scsi is ugly because
it sin
Am 12.06.2019 um 14:04 hat Stefan Hajnoczi geschrieben:
> When the 'cont' command resumes guest execution the vm change state
> handlers are invoked. Unfortunately there is no explicit ordering
> between vm change state handlers. When two layers of code both use vm
> change state handlers, we don
Patchew URL:
https://patchew.org/QEMU/20190612120421.20336-1-stefa...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v4] virtio-scsi: restart DMA after iothread
Type: series
Message-id
On 12/06/19 14:04, Stefan Hajnoczi wrote:
> When the 'cont' command resumes guest execution the vm change state
> handlers are invoked. Unfortunately there is no explicit ordering
> between vm change state handlers. When two layers of code both use vm
> change state handlers, we don't control whi
When the 'cont' command resumes guest execution the vm change state
handlers are invoked. Unfortunately there is no explicit ordering
between vm change state handlers. When two layers of code both use vm
change state handlers, we don't control which handler runs first.
virtio-scsi with iothreads
