Skip to content
Snippets Groups Projects
  1. Dec 17, 2015
    • Eric Blake's avatar
      cpu: Convert CpuInfo into flat union · 86f4b687
      Eric Blake authored
      
      The CpuInfo struct is used only by the 'query-cpus' output
      command, so we are free to modify it by adding fields (clients
      are already supposed to ignore unknown output fields), or by
      changing optional members to mandatory, while still keeping
      QMP wire compatibility with older versions of qemu.
      
      When qapi type CpuInfo was originally created for 0.14, we had
      no notion of a flat union, and instead just listed a bunch of
      optional fields with documentation about the mutually-exclusive
      choice of which instruction pointer field(s) would be provided
      for a given architecture.  But now that we have flat unions and
      introspection, it is better to segregate off which fields will
      be provided according to the actual architecture.  With this in
      place, we no longer need the fields to be optional, because the
      choice of the new 'arch' discriminator serves that role.
      
      This has an additional benefit: the old all-in-one struct was
      the only place in the code base that had a case-sensitive
      naming of members 'pc' vs. 'PC'.  Separating these spellings
      into different branches of the flat union will allow us to add
      restrictions against future case-insensitive collisions, since
      that is generally a poor interface practice.
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
      [Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      86f4b687
  2. Nov 26, 2015
  3. Nov 06, 2015
  4. Nov 05, 2015
  5. Oct 08, 2015
  6. Sep 30, 2015
  7. Sep 09, 2015
  8. Sep 07, 2015
  9. Aug 14, 2015
    • Paolo Bonzini's avatar
      exec: drop cpu_can_do_io, just read cpu->can_do_io · 414b15c9
      Paolo Bonzini authored
      
      After commit 626cf8f4 (icount: set can_do_io outside TB execution,
      2014-12-08), can_do_io is set to 1 if not executing code.  It is
      no longer necessary to make this assumption in cpu_can_do_io.
      
      It is also possible to remove the use_icount test, simply by
      never setting cpu->can_do_io to 0 unless use_icount is true.
      
      With these changes cpu_can_do_io boils down to a read of
      cpu->can_do_io.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      414b15c9
  10. Jul 24, 2015
  11. Jul 09, 2015
  12. Jul 01, 2015
    • Paolo Bonzini's avatar
      main-loop: introduce qemu_mutex_iothread_locked · afbe7053
      Paolo Bonzini authored
      
      This function will be used to avoid recursive locking of the iothread lock
      whenever address_space_rw/ld*/st* are called with the BQL held, which is
      almost always the case.
      
      Tracking whether the iothread is owned is very cheap (just use a TLS
      variable) but requires some care because now the lock must always be
      taken with qemu_mutex_lock_iothread().  Previously this wasn't the case.
      Outside TCG mode this is not a problem.  In TCG mode, we need to be
      careful and avoid the "prod out of compiled code" step if already
      in a VCPU thread.  This is easily done with a check on current_cpu,
      i.e. qemu_in_vcpu_thread().
      
      Hopefully, multithreaded TCG will get rid of the whole logic to kick
      VCPUs whenever an I/O event occurs!
      
      Cc: Frederic Konrad <fred.konrad@greensocs.com>
      Message-Id: <1434646046-27150-3-git-send-email-pbonzini@redhat.com>
      Reviewed-by: default avatarFam Zheng <famz@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      afbe7053
    • Paolo Bonzini's avatar
      main-loop: use qemu_mutex_lock_iothread consistently · 2e7f7a3c
      Paolo Bonzini authored
      
      The next patch will require the BQL to be always taken with
      qemu_mutex_lock_iothread(), while right now this isn't the case.
      
      Outside TCG mode this is not a problem.  In TCG mode, we need to be
      careful and avoid the "prod out of compiled code" step if already
      in a VCPU thread.  This is easily done with a check on current_cpu,
      i.e. qemu_in_vcpu_thread().
      
      Hopefully, multithreaded TCG will get rid of the whole logic to kick
      VCPUs whenever an I/O event occurs!
      
      Cc: Frederic Konrad <fred.konrad@greensocs.com>
      Message-Id: <1434646046-27150-2-git-send-email-pbonzini@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2e7f7a3c
  13. Jun 22, 2015
  14. Jun 12, 2015
    • Juan Quintela's avatar
      migration: Use normal VMStateDescriptions for Subsections · 5cd8cada
      Juan Quintela authored
      
      We create optional sections with this patch.  But we already have
      optional subsections.  Instead of having two mechanism that do the
      same, we can just generalize it.
      
      For subsections we just change:
      
      - Add a needed function to VMStateDescription
      - Remove VMStateSubsection (after removal of the needed function
        it is just a VMStateDescription)
      - Adjust the whole tree, moving the needed function to the corresponding
        VMStateDescription
      
      Signed-off-by: default avatarJuan Quintela <quintela@redhat.com>
      5cd8cada
  15. Jun 05, 2015
  16. May 14, 2015
  17. Apr 30, 2015
  18. Mar 25, 2015
    • Peter Crosthwaite's avatar
      cpus: Don't kick un-realized cpus. · bdd459a0
      Peter Crosthwaite authored
      
      following a4649824, it's now possible for
      there to be attempts to take the BQL before CPUs have been realized in
      cases where a machine model inits peripherals before the first CPU.
      
      BQL lock aquisition kicks the first_cpu, leading to a segfault if this
      happens pre-realize. Guard the CPU kick routine to perform no action for
      a CPU that doesn't exist or doesn't have a thread yet.
      
      There was a fix to this with commit
      6b49809c, but the check there misses
      the case where the CPU has been inited and not realized. Strengthen the
      check to make sure that the first_cpu has a thread (i.e. it is
      realized) before allowing the kick.
      
      Signed-off-by: default avatarPeter Crosthwaite <peter.crosthwaite@xilinx.com>
      Message-Id: <1427107689-6946-1-git-send-email-peter.crosthwaite@xilinx.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      bdd459a0
  19. Mar 18, 2015
    • Alexey Kardashevskiy's avatar
      profiler: Reenable built-in profiler · 89d5cbdd
      Alexey Kardashevskiy authored
      
      2ed1ebcf "timer: replace time() with QEMU_CLOCK_HOST" broke compile
      when configured with --enable-profiler. Turned out the profiler has been
      broken for a while.
      
      This does s/qemu_time/tcg_time/ as the profiler only works in a TCG mode.
      This also fixes the compile error.
      
      This changes profile_getclock() to return nanoseconds rather than
      CPU ticks as the "profile" HMP command prints seconds and there is no
      platform-independent way to get ticks-per-second rate.
      Since TCG is quite slow and get_clock() returns nanoseconds (fine
      enough), this should not affect precision much.
      
      This removes unused qemu_time_start and tlb_flush_time.
      
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Message-Id: <1426478258-29961-1-git-send-email-aik@ozlabs.ru>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      89d5cbdd
  20. Mar 10, 2015
    • Borislav Petkov's avatar
      memsave: Improve and disambiguate error message · 0dc9daf0
      Borislav Petkov authored
      
      When requesting a size which cannot be read, the error message shows
      a different address which is misleading to the user and it looks like
      something's wrong with the address parsing. This is because the input
      @addr variable is incremented in the memory dumping loop:
      
      (qemu) memsave 0xffffffff8418069c 0xb00000 mem
      Invalid addr 0xffffffff849ffe9c specified
      
      Fix that by saving the original address and size and use them in the
      error message:
      
      (qemu) memsave 0xffffffff8418069c 0xb00000 mem
      Invalid addr 0xffffffff8418069c/size 11534336 specified
      
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      0dc9daf0
  21. Mar 02, 2015
    • Paolo Bonzini's avatar
      cpus: be more paranoid in avoiding deadlocks · 21618b3e
      Paolo Bonzini authored
      
      For good measure, ensure that the following sequence:
      
         thread 1 calls qemu_mutex_lock_iothread
         thread 2 calls qemu_mutex_lock_iothread
         VCPU thread are created
         VCPU thread enters execution loop
      
      results in the VCPU threads letting the other two threads run
      and obeying iothread_requesting_mutex even if the VCPUs are
      not halted.  To do this, check iothread_requesting_mutex
      before execution starts.
      
      Tested-by: default avatarLeon Alrae <leon.alrae@imgtec.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      21618b3e
    • Paolo Bonzini's avatar
      cpus: fix deadlock and segfault in qemu_mutex_lock_iothread · 6b49809c
      Paolo Bonzini authored
      
      When two threads (other than the low-priority TCG VCPU thread)
      are competing for the iothread lock, a deadlock can happen.  This
      is because iothread_requesting_mutex is set to false by the first
      thread that gets the mutex, and then the VCPU thread might never
      yield from the execution loop.  If iothread_requesting_mutex is
      changed from a bool to a counter, the deadlock is fixed.
      
      However, there is another bug in qemu_mutex_lock_iothread that
      can be triggered by the new call_rcu thread.  The bug happens
      if qemu_mutex_lock_iothread is called before the CPUs are
      created.  In that case, first_cpu is NULL and the caller
      segfaults in qemu_mutex_lock_iothread.  To fix this, just
      do not do the kick if first_cpu is NULL.
      
      Reported-by: default avatarLeon Alrae <leon.alrae@imgtec.com>
      Reported-by: default avatarAndreas Gustafsson <gson@gson.org>
      Tested-by: default avatarLeon Alrae <leon.alrae@imgtec.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6b49809c
  22. Feb 16, 2015
  23. Feb 02, 2015
    • Paolo Bonzini's avatar
      cpu-exec: simplify init_delay_params · 2e91cc62
      Paolo Bonzini authored
      
      With the introduction of QEMU_CLOCK_VIRTUAL_RT, the computation of
      sc->diff_clk can be simplified nicely:
      
              qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              qemu_clock_get_ns(QEMU_CLOCK_REALTIME) +
              cpu_get_clock_offset()
      
           =  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) - cpu_get_clock_offset())
      
           =  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) + timers_state.cpu_clock_offset)
      
           =  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT)
      
      Cc: Sebastian Tanase <sebastian.tanase@openwide.fr>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2e91cc62
  24. Jan 14, 2015
  25. Dec 20, 2014
Loading