1. 16 6月, 2018 1 次提交
    • E
      tcg: remove tb_lock · 0ac20318
      Emilio G. Cota 提交于
      Use mmap_lock in user-mode to protect TCG state and the page descriptors.
      In !user-mode, each vCPU has its own TCG state, so no locks needed.
      Per-page locks are used to protect the page descriptors.
      
      Per-TB locks are used in both modes to protect TB jumps.
      
      Some notes:
      
      - tb_lock is removed from notdirty_mem_write by passing a
        locked page_collection to tb_invalidate_phys_page_fast.
      
      - tcg_tb_lookup/remove/insert/etc have their own internal lock(s),
        so there is no need to further serialize access to them.
      
      - do_tb_flush is run in a safe async context, meaning no other
        vCPU threads are running. Therefore acquiring mmap_lock there
        is just to please tools such as thread sanitizer.
      
      - Not visible in the diff, but tb_invalidate_phys_page already
        has an assert_memory_lock.
      
      - cpu_io_recompile is !user-only, so no mmap_lock there.
      
      - Added mmap_unlock()'s before all siglongjmp's that could
        be called in user-mode while mmap_lock is held.
        + Added an assert for !have_mmap_lock() after returning from
          the longjmp in cpu_exec, just like we do in cpu_exec_step_atomic.
      
      Performance numbers before/after:
      
      Host: AMD Opteron(tm) Processor 6376
      
                       ubuntu 17.04 ppc64 bootup+shutdown time
      
        700 +-+--+----+------+------------+-----------+------------*--+-+
            |    +    +      +            +           +           *B    |
            |         before ***B***                            ** *    |
            |tb lock removal ###D###                         ***        |
        600 +-+                                           ***         +-+
            |                                           **         #    |
            |                                        *B*          #D    |
            |                                     *** *         ##      |
        500 +-+                                ***           ###      +-+
            |                             * ***           ###           |
            |                            *B*          # ##              |
            |                          ** *          #D#                |
        400 +-+                      **            ##                 +-+
            |                      **           ###                     |
            |                    **           ##                        |
            |                  **         # ##                          |
        300 +-+  *           B*          #D#                          +-+
            |    B         ***        ###                               |
            |    *       **       ####                                  |
            |     *   ***      ###                                      |
        200 +-+   B  *B     #D#                                       +-+
            |     #B* *   ## #                                          |
            |     #*    ##                                              |
            |    + D##D#     +            +           +            +    |
        100 +-+--+----+------+------------+-----------+------------+--+-+
                 1    8      16      Guest CPUs       48           64
        png: https://imgur.com/HwmBHXe
      
                    debian jessie aarch64 bootup+shutdown time
      
        90 +-+--+-----+-----+------------+------------+------------+--+-+
           |    +     +     +            +            +            +    |
           |         before ***B***                                B    |
        80 +tb lock removal ###D###                              **D  +-+
           |                                                   **###    |
           |                                                 **##       |
        70 +-+                                             ** #       +-+
           |                                             ** ##          |
           |                                           **  #            |
        60 +-+                                       *B  ##           +-+
           |                                       **  ##               |
           |                                    ***  #D                 |
        50 +-+                               ***   ##                 +-+
           |                             * **   ###                     |
           |                           **B*  ###                        |
        40 +-+                     ****  # ##                         +-+
           |                   ****     #D#                             |
           |             ***B**      ###                                |
        30 +-+    B***B**        ####                                 +-+
           |    B *   *     # ###                                       |
           |     B       ###D#                                          |
        20 +-+   D  ##D##                                             +-+
           |      D#                                                    |
           |    +     +     +            +            +            +    |
        10 +-+--+-----+-----+------------+------------+------------+--+-+
                1     8     16      Guest CPUs        48           64
        png: https://imgur.com/iGpGFtv
      
      The gains are high for 4-8 CPUs. Beyond that point, however, unrelated
      lock contention significantly hurts scalability.
      Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Signed-off-by: NEmilio G. Cota <cota@braap.org>
      Signed-off-by: NRichard Henderson <richard.henderson@linaro.org>
      0ac20318
  2. 25 5月, 2018 1 次提交
  3. 30 4月, 2018 19 次提交
  4. 01 4月, 2018 1 次提交
  5. 20 3月, 2018 1 次提交
    • I
      Use cpu_create(type) instead of cpu_init(cpu_model) · 2278b939
      Igor Mammedov 提交于
      With all targets defining CPU_RESOLVING_TYPE, refactor
      cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model)
      so that callers won't have to know internal resolving cpu
      type. Place it in exec.c so it could be called from both
      target independed vl.c and *-user/main.c.
      
      That allows us to stop abusing cpu type from
        MachineClass::default_cpu_type
      as resolver class in vl.c which were confusing part of
      cpu_parse_cpu_model().
      
      Also with new parse_cpu_model(), the last users of cpu_init()
      in null-machine.c and bsd/linux-user targets could be switched
      to cpu_create() API and cpu_init() API will be removed by
      follow up patch.
      
      With no longer users left remove MachineState::cpu_model field,
      new code should use MachineState::cpu_type instead and
      leave cpu_model parsing to generic code in vl.c.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1518000027-274608-5-git-send-email-imammedo@redhat.com>
      [ehabkost: Fix bsd-user build error]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      2278b939
  6. 17 3月, 2018 1 次提交
    • M
      target/xtensa: add linux-user support · ba7651fb
      Max Filippov 提交于
      Import list of syscalls from the kernel source. Conditionalize code/data
      that is only used with softmmu. Implement exception handlers. Implement
      signal hander (only the core registers for now, no coprocessors or TIE).
      
      Cc: Riku Voipio <riku.voipio@iki.fi>
      Cc: Laurent Vivier <laurent@vivier.eu>
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      ba7651fb
  7. 12 3月, 2018 1 次提交
    • T
      Polish the version strings containing the package version · 7e563bfb
      Thomas Huth 提交于
      Since commit 67a1de0d there is no space anymore between the
      version number and the parentheses when running configure with
      --with-pkgversion=foo :
      
       $ qemu-system-s390x --version
       QEMU emulator version 2.11.50(foo)
      
      But the space is included when building without that option
      when building from a git checkout:
      
       $ qemu-system-s390x --version
       QEMU emulator version 2.11.50 (v2.11.0-1494-gbec9c64e-dirty)
      
      The same confusion exists with the "query-version" QMP command.
      Let's fix this by introducing a proper QEMU_FULL_VERSION definition
      that includes the space and parentheses, while the QEMU_PKGVERSION
      should just cleanly contain the package version string itself.
      Note that this also changes the behavior of the "query-version" QMP
      command (the space and parentheses are not included there anymore),
      but that's supposed to be OK since the strings there are not meant
      to be parsed by other tools.
      
      Fixes: 67a1de0d
      Buglink: https://bugs.launchpad.net/qemu/+bug/1673373Signed-off-by: NThomas Huth <thuth@redhat.com>
      Message-Id: <1518692807-25859-1-git-send-email-thuth@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7e563bfb
  8. 10 3月, 2018 1 次提交
  9. 07 3月, 2018 1 次提交
  10. 26 2月, 2018 2 次提交
  11. 19 2月, 2018 1 次提交
  12. 31 1月, 2018 2 次提交
  13. 23 1月, 2018 2 次提交
    • P
      linux-user: wrap fork() in a start/end exclusive section · 06065c45
      Peter Maydell 提交于
      When we do a fork() in usermode emulation, we need to be in
      a start/end exclusive section, so that we can ensure that no
      other thread is in an RCU section. Otherwise you can get this
      deadlock:
      
      - fork thread: has mmap_lock, waits for rcu_sync_lock
        (because rcu_init_lock() is registered as a pthread_atfork() hook)
      - RCU thread: has rcu_sync_lock, waits for rcu_read_(un)lock
      - another CPU thread: in RCU critical section, waits for mmap_lock
      
      This can show up if you have a heavily multithreaded guest program
      that does a fork().
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reported-by: NStuart Monteith <stuart.monteith@linaro.org>
      Message-Id: <1512650481-1723-1-git-send-email-peter.maydell@linaro.org>
      Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
      06065c45
    • P
      linux-user: Fix locking order in fork_start() · 024949ca
      Peter Maydell 提交于
      Our locking order is that the tb lock should be taken
      inside the mmap_lock, but fork_start() grabs locks the
      other way around. This means that if a heavily multithreaded
      guest process (such as Java) calls fork() it can deadlock,
      with the thread that called fork() stuck in fork_start()
      with the tb lock and waiting for the mmap lock, but some
      other thread in tb_find() with the mmap lock and waiting
      for the tb lock. The cpu_list_lock() should also always be
      taken last, not first.
      
      Fix this by making fork_start() grab the locks in the
      right order. The order in which we drop locks doesn't
      matter, so we leave fork_end() the way it is.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Cc: qemu-stable@nongnu.org
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Message-Id: <1512397331-15238-1-git-send-email-peter.maydell@linaro.org>
      Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
      024949ca
  14. 11 1月, 2018 1 次提交
  15. 05 1月, 2018 1 次提交
  16. 19 12月, 2017 1 次提交
  17. 18 12月, 2017 1 次提交
  18. 08 11月, 2017 2 次提交