qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [RFC v2 00/11] cpu-exec: Safe work in quiescent state


From: Sergey Fedorov
Subject: [Qemu-devel] [RFC v2 00/11] cpu-exec: Safe work in quiescent state
Date: Thu, 7 Jul 2016 00:14:52 +0300

From: Sergey Fedorov <address@hidden>

Hi,

This is a v2 of the RFC series [3] that was a follow-up for a discussion
on the subject [1]. This is sill marked as FRC becuse it laks bsd-user
support.

Basically, this series suggests a way to perform some operations in
quiescent state. The goal is to implement such a mechanism which can be
used for safe translation buffer flush in multi-threaded user-mode
emulation (and later in MTTCG) and merge it into mainline as soon as
possible.

This series is a more elaborated version of the original series since
there was some positive feedback and I'd appreciate some comments from
maintainers this time. 

The first two patches are some useful tweak from Alex's MTTCG trees.

The patches 3 through 8 are arrangements for the patch 9 which adds
support for CPU work in linux-user. This wouldn't make any sense without
the patch 10 which is the subject matter of this series. Although there
is nothing special to do in case of single-threaded round-robin CPU loop
of current system-mode emulation to ensure quiescent state, that is
shown in the patch 10, how it would look like in MTTCG. The last patch
actually employs this new mechanism making translation buffer flush
thread safe.

The considerations on expensiveness of work item dynamic allocation [2]
was not taken into account. I'll just mention here that the desired
effect can be achieved by either using dynamic arrays for CPU work
queues or making queue_work_on_cpu() from the patch 3 a public interface
thus allowing to use preallocated work items.

I would like your comments in order to produce something upstreamable
quickly!

This series is available at a public git repository:

    https://github.com/sergefdrv/qemu.git safe-cpu-work-v2

Summary of changes in v2:
 - atomic_dec_fetch() used to decrement 'safe_work_pending'
 - more work to use/fix passing CPUState to run_on_cpu helpers
 - instead of wrapping conditional variables access, use QemuMutex and QemuCond
   in linux-user and just wrap getting of the relevant mutex.
 - document new public API
 - Rename 'tcg_pending_cpus' to 'tcg_pending_threads'

Kind regards,
Sergey

[1] http://thread.gmane.org/gmane.comp.emulators.qemu/417599
[2] http://thread.gmane.org/gmane.comp.emulators.qemu/407030/focus=407039
[3] http://thread.gmane.org/gmane.comp.emulators.qemu/420363

Alex Bennée (2):
  atomic: introduce atomic_dec_fetch.
  cpus: pass CPUState to run_on_cpu helpers

Sergey Fedorov (9):
  cpus: Move common code out of {async_,}run_on_cpu()
  cpus: Wrap mutex used to protect CPU work
  cpus: Rename flush_queued_work()
  linux-user: Use QemuMutex and QemuCond
  linux-user: Rework exclusive operation mechanism
  linux-user: Add qemu_cpu_is_self() and qemu_cpu_kick()
  linux-user: Support CPU work queue
  cpu-exec-common: Introduce async_safe_run_on_cpu()
  tcg: Make tb_flush() thread safe

 cpu-exec-common.c          | 132 +++++++++++++++++++++++++++++++++++++++++++++
 cpus.c                     | 106 +++++++-----------------------------
 hw/i386/kvm/apic.c         |   3 +-
 hw/i386/kvmvapic.c         |   6 +--
 hw/ppc/ppce500_spin.c      |  31 ++++-------
 hw/ppc/spapr.c             |   6 +--
 hw/ppc/spapr_hcall.c       |  17 +++---
 include/exec/exec-all.h    |  31 +++++++++++
 include/qemu/atomic.h      |   4 ++
 include/qom/cpu.h          |  22 ++++++--
 kvm-all.c                  |  21 +++-----
 linux-user/main.c          |  94 ++++++++++++++++++++------------
 target-i386/helper.c       |  19 +++----
 target-i386/kvm.c          |   6 +--
 target-s390x/cpu.c         |   4 +-
 target-s390x/cpu.h         |   7 +--
 target-s390x/kvm.c         |  98 ++++++++++++++++-----------------
 target-s390x/misc_helper.c |   4 +-
 translate-all.c            |  13 +++--
 19 files changed, 371 insertions(+), 253 deletions(-)

-- 
1.9.1




reply via email to

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