From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34060)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <a.rigo@virtualopensystems.com>) id 1bAgHx-0004sb-IK
	for qemu-devel@nongnu.org; Wed, 08 Jun 2016 12:25:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <a.rigo@virtualopensystems.com>) id 1bAgHu-0002lX-4r
	for qemu-devel@nongnu.org; Wed, 08 Jun 2016 12:25:05 -0400
Received: from mail-io0-x232.google.com ([2607:f8b0:4001:c06::232]:36483)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <a.rigo@virtualopensystems.com>) id 1bAgHt-0002lQ-Uf
	for qemu-devel@nongnu.org; Wed, 08 Jun 2016 12:25:02 -0400
Received: by mail-io0-x232.google.com with SMTP id n127so13952419iof.3
	for <qemu-devel@nongnu.org>; Wed, 08 Jun 2016 09:25:01 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <87a8ivhflj.fsf@linaro.org>
References: <57583182.3090701@gmail.com> <87a8ivhflj.fsf@linaro.org>
From: alvise rigo <a.rigo@virtualopensystems.com>
Date: Wed, 8 Jun 2016 18:24:46 +0200
Message-ID: <CAH47eN15bfnzCXBO2hz7Y1Jp7LRWCvyDogxYCuZ66pDE=7m6iA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC 03/10] cpus: Introduce async_wait_run_on_cpu()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>
Cc: Sergey Fedorov <serge.fdrv@gmail.com>, MTTCG Devel <mttcg@listserver.greensocs.com>, QEMU Developers <qemu-devel@nongnu.org>, Jani Kokkonen <jani.kokkonen@huawei.com>, Claudio Fontana <claudio.fontana@huawei.com>, VirtualOpenSystems Technical Team <tech@virtualopensystems.com>, =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= <fred.konrad@greensocs.com>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <rth@twiddle.net>, "Emilio G. Cota" <cota@braap.org>, Peter Maydell <peter.maydell@linaro.org>

I think that async_safe_run_on_cpu() does a different thing: it
queries a job to the target vCPU and wants all the other to "observe"
the submitted task. However, we will have the certainty that only the
target vCPU observed the task, the other might still be running in the
guest code.

alvise

On Wed, Jun 8, 2016 at 5:20 PM, Alex Benn=C3=A9e <alex.bennee@linaro.org> w=
rote:
>
> Sergey Fedorov <serge.fdrv@gmail.com> writes:
>
>> On 08/06/16 17:10, alvise rigo wrote:
>>> Using run_on_cpu() we might deadlock QEMU if other vCPUs are waiting
>>> for the current vCPU. We need to exit from the vCPU loop in order to
>>> avoid this.
>>
>> I see, we could deadlock indeed. Alternatively, we may want fix
>> run_on_cpu() to avoid waiting for completion by itself when called from
>> CPU loop.
>
> async_safe_run_on_cpu can't deadlock as all vCPUs are suspended (or
> waiting) for the work to complete. The tasks are run in strict order so
> if you queued async tasks for other vCPUs first you could ensure
> everything is in the state you want it when you finally service the
> calling vCPU.
>
>>
>> Kind regards,
>> Sergey
>
>
> --
> Alex Benn=C3=A9e