From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45540)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1bB7ry-0002or-AK
	for qemu-devel@nongnu.org; Thu, 09 Jun 2016 17:52:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1bB7rt-00067q-33
	for qemu-devel@nongnu.org; Thu, 09 Jun 2016 17:52:05 -0400
Received: from mail-lf0-x243.google.com ([2a00:1450:4010:c07::243]:36440)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1bB7rs-00067g-Rm
	for qemu-devel@nongnu.org; Thu, 09 Jun 2016 17:52:01 -0400
Received: by mail-lf0-x243.google.com with SMTP id h68so4561141lfh.3
	for <qemu-devel@nongnu.org>; Thu, 09 Jun 2016 14:52:00 -0700 (PDT)
From: Sergey Fedorov <serge.fdrv@gmail.com>
Message-ID: <5759E4FD.5020608@gmail.com>
Date: Fri, 10 Jun 2016 00:51:57 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] exec: Safe work in quiescent state
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: QEMU Developers <qemu-devel@nongnu.org>
Cc: MTTCG Devel <mttcg@listserver.greensocs.com>, =?UTF-8?B?S09OUkFEIEZyw6lkw6lyaWM=?= <fred.konrad@greensocs.com>, Alvise Rigo <a.rigo@virtualopensystems.com>, "Emilio G. Cota" <cota@braap.org>, =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>, Richard Henderson <rth@twiddle.net>, Peter Maydell <peter.maydell@linaro.org>

Hi,

For certain kinds of tasks we might need a quiescent state to perform an
operation safely. Quiescent state means no CPU thread executing, and
probably BQL held as well. The tasks could include:
- Translation buffer flush (user and system-mode)
- Cross-CPU TLB flush (system-mode)
- Exclusive operation emulation (user-mode)

If we use a single shared translation buffer which is not managed by RCU
and simply flushed when full, we'll need a quiescent state to flush it
safely.

In multi-threaded TCG, cross-CPU TLB flush from TCG helpers could
probably be made with async_run_on_cpu(). I suppose it is always the
guest system that needs to synchronise this operation properly. And as
soon as we request the target CPU to exit its execution loop for serving
the asynchronous work, we should probably be okay to continue execution
on the CPU requested the operation while the target CPU executing till
the end of its current TB before it actually flushed its TLB.

As of slow-path LL/SC emulation in multi-threaded TCG, cross-CPU TLB
flushes (actually TLB flushes on all CPUs) must me done synchronously
and thus might require quiescent state.

Exclusive operation emulation in user-mode is currently implemented in
this manner, see for start_exclusive(). It might change to some generic
mechanism of atomic/exclusive instruction emulation for system and
user-mode.

It looks like we need to implement a common mechanism to perform safe
work in a quiescent state which could work in both system and user-mode,
at least for safe translation bufferflush in user-mode and MTTCG. I'm
going to implement such a mechanism. I would appreciate any suggestions,
comments and remarks.

Thanks,
Sergey