Skip to content
Snippets Groups Projects
  1. Nov 04, 2015
    • John Snow's avatar
      configure: disallow ccache during compile tests · 5e4dfd3d
      John Snow authored
      
      If the user is using ccache during the configuration step,
      it may interfere with some of the configuration tests,
      particularly the "Is ccache interfering with macro analysis" step,
      which is a bit of a poetic problem.
      
      1) Disallow ccache from reading from the cache during configure,
         but don't disable it entirely to allow us to see if it causes other
         problems.
      
      2) Force off CCACHE_CPP2 during the ccache test to get a deterministic
         answer over whether or not we need to enable that feature later.
      
      Signed-off-by: default avatarJohn Snow <jsnow@redhat.com>
      Message-Id: <1446055000-29150-1-git-send-email-jsnow@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5e4dfd3d
    • Stefan Weil's avatar
      cpu-exec: Fix compiler warning (-Werror=clobbered) · 0448f5f8
      Stefan Weil authored
      
      Reloading of local variables after sigsetjmp is only needed for some
      buggy compilers.
      
      The code which should reload these variables causes compiler warnings
      with gcc 4.7 when compiler optimizations are enabled:
      
      cpu-exec.c:204:15: error:
       variable ‘cpu’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
      cpu-exec.c:207:15: error:
       variable ‘cc’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
      cpu-exec.c:202:28: error:
       argument ‘env’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
      
      Now this code is only used for compilers which need it
      (and gcc 4.5.x, x > 0 which does not need it but won't give warnings).
      
      There were bug reports for clang and gcc 4.5.0, while gcc 4.5.1
      was reported to work fine without the reload code. For clang it
      is not clear which versions are affected, so simply keep the status quo
      for all clang compilations. This can be improved later.
      
      Signed-off-by: default avatarStefan Weil <sw@weilnetz.de>
      Message-Id: <1443266606-21400-1-git-send-email-sw@weilnetz.de>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0448f5f8
    • Paolo Bonzini's avatar
      memory: call begin, log_start and commit when registering a new listener · 680a4783
      Paolo Bonzini authored
      
      This ensures that cpu_reload_memory_map() is called as soon as
      tcg_cpu_address_space_init() is called, and before cpu->memory_dispatch
      is used.  qemu-system-s390x never changes the address spaces after
      tcg_cpu_address_space_init() is called, and thus tcg_commit() is never
      called.  This causes a SIGSEGV.
      
      Because memory_map_init() will now call mem_commit(), we have to
      initialize io_mem_* before address_space_memory and friends.
      
      Reported-by: default avatarPhilipp Kern <pkern@debian.org>
      Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Fixes: 0a1c71ce
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      680a4783
    • Eduardo Habkost's avatar
      megasas: Use qemu_hw_version() instead of QEMU_VERSION · 69fbd0ea
      Eduardo Habkost authored
      
      Guest visible data shouldn't change with a simple QEMU upgrade, so use
      qemu_hw_version() to ensure it won't change (as long as the machine
      class being used has hw_version set).
      
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: qemu-block@nongnu.org
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Acked-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1446233769-7892-4-git-send-email-ehabkost@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      69fbd0ea
    • Eduardo Habkost's avatar
      osdep: Rename qemu_{get, set}_version() to qemu_{, set_}hw_version() · 35c2c8dc
      Eduardo Habkost authored
      
      This makes the purpose of the function clearer: it is not about the
      version of QEMU that's running, but the version string exposed in the
      emulated hardware.
      
      Cc: Andrzej Zaborowski <balrogg@gmail.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: John Snow <jsnow@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarJohn Snow <jsnow@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1446233769-7892-3-git-send-email-ehabkost@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      35c2c8dc
    • Eduardo Habkost's avatar
      pc: Set hw_version on all machine classes · de796d93
      Eduardo Habkost authored
      
      In 2012, QEMU had a bug where it exposed QEMU version information to the
      guest, meaning a QEMU upgrade would expose different hardware to the
      guest OS even if the same machine-type is being used.
      
      The bug was fixed by commit 93bfef4c, on
      all machines up to pc-1.0. But we kept introducing the same bug on all
      newer machines since then. That means we are breaking guest ABI every
      time QEMU was upgraded.
      
      Fix this by setting the hw_version on all PC machines, making sure the
      hardware won't change when upgrading QEMU.
      
      Note that QEMU_VERSION was "1.0" in QEMU 1.0, but starting on QEMU
      1.1.0, it started following the "x.y.0" pattern. We have to follow it,
      to make sure we use the right QEMU_VERSION string from each QEMU
      release.
      
      The 2.5 machine classes could have hw_version unset, because the default
      value for qemu_get_version() is QEMU_VERSION. But I decided to set it
      explicitly to QEMU_VERSION so we don't forget to update it to "2.5.0"
      after we release 2.5.0 and create a 2.6 machine class.
      
      Reported-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <1446233769-7892-2-git-send-email-ehabkost@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      de796d93
    • Paolo Bonzini's avatar
      qemu-log: remove -d ioport · ddcc8e9d
      Paolo Bonzini authored
      
      It was disabled at compile-time, and is now replaced by tracepoints.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      ddcc8e9d
    • Paolo Bonzini's avatar
      ioport: do not use CPU_LOG_IOPORT · 6f94b7d9
      Paolo Bonzini authored
      
      These messages are disabled by default; a perfect usecase for tracepoints,
      which in fact already exist.  Add the missing information to them and
      stop using qemu_log_mask.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6f94b7d9
    • Paolo Bonzini's avatar
      target-i386: fix pcmpxstrx equal-ordered (strstr) mode · 54c54f8b
      Paolo Bonzini authored
      
      In this mode, referring an invalid element of the source forces the
      result to false (table 4-7, last column) but referring an invalid
      element of the destination forces the result to true, so the outer
      loop should still be run even if some elements of the destination
      will be invalid.  They will be avoided in the inner loop, which
      correctly bounds "i" to validd, but they will still contribute to a
      positive outcome of the search.
      
      This fixes tst_strstr in glibc 2.17.
      
      Reported-by: default avatarFlorian Weimer <fweimer@redhat.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      54c54f8b
  2. Nov 02, 2015
  3. Oct 29, 2015
  4. Oct 28, 2015
  5. Oct 27, 2015
Loading