qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4] virtio-scsi: restart DMA after iothread


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v4] virtio-scsi: restart DMA after iothread
Date: Mon, 17 Jun 2019 14:29:22 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

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't control which handler runs first.
> 
> virtio-scsi with iothreads hits a deadlock when a failed SCSI command is
> restarted and completes before the iothread is re-initialized.
> 
> This patch introduces priorities for VM change state handlers so the
> IOThread is guaranteed to be initialized before DMA requests are
> restarted.
> 
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
> v4:
> Paolo and Michael were interested in a priorities system.  Kevin wasn't
> convinced.  Here is a patch implementing the priorities approach so you
> can decide whether you prefer this or not.

I still prefer the v3 approach that reflects the actual dependencies in
the code. With the priorities approach, we try to represent a tree of
devices (a structure we already have) with an additional flat list of
numbers. While these numbers can actually provide all the information
that we need in practice in this specific case, it still feels a bit
hacky and might not be extensible to future cases.

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.

Kevin



reply via email to

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