Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 09 2月, 2016 1 次提交
  3. 23 10月, 2015 2 次提交
  5. 16 9月, 2015 1 次提交
  7. 05 6月, 2015 1 次提交
  9. 29 5月, 2014 1 次提交
  11. 22 11月, 2013 1 次提交
    • P
      target-i386: yield to another VCPU on PAUSE · b5fc314b
      由 Paolo Bonzini 提交于 
      After commit b1bbfe72 (aio / timers: On timer modification, qemu_notify
or aio_notify, 2013-08-21) FreeBSD guests report a huge slowdown.

The problem shows up as soon as FreeBSD turns out its periodic (~1 ms)
tick, but the timers are only the trigger for a pre-existing problem.

Before the offending patch, setting a timer did a timer_settime system call.

After, setting the timer exits the event loop (which uses poll) and
reenters it with a new deadline.  This does not cause any slowdown; the
difference is between one system call (timer_settime and a signal
delivery (SIGALRM) before the patch, and two system calls afterwards
(write to a pipe or eventfd + calling poll again when re-entering the
event loop).

Unfortunately, the exit/enter causes the main loop to grab the iothread
lock, which in turns kicks the VCPU thread out of execution.  This
causes TCG to execute the next VCPU in its round-robin scheduling of
VCPUS.  When the second VCPU is mostly unused, FreeBSD runs a "pause"
instruction in its idle loop which only burns cycles without any
progress.  As soon as the timer tick expires, the first VCPU runs
the interrupt handler but very soon it sets it again---and QEMU
then goes back doing nothing in the second VCPU.

The fix is to make the pause instruction do "cpu_loop_exit".
Reported-by: NLuigi Rizzo <rizzo@iet.unipi.it>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b5fc314b
  13. 21 11月, 2013 1 次提交
    • P
      target-i386: yield to another VCPU on PAUSE · 81f3053b
      由 Paolo Bonzini 提交于 
      After commit b1bbfe72 (aio / timers: On timer modification, qemu_notify
or aio_notify, 2013-08-21) FreeBSD guests report a huge slowdown.

The problem shows up as soon as FreeBSD turns out its periodic (~1 ms)
tick, but the timers are only the trigger for a pre-existing problem.

Before the offending patch, setting a timer did a timer_settime system call.

After, setting the timer exits the event loop (which uses poll) and
reenters it with a new deadline.  This does not cause any slowdown; the
difference is between one system call (timer_settime and a signal
delivery (SIGALRM) before the patch, and two system calls afterwards
(write to a pipe or eventfd + calling poll again when re-entering the
event loop).

Unfortunately, the exit/enter causes the main loop to grab the iothread
lock, which in turns kicks the VCPU thread out of execution.  This
causes TCG to execute the next VCPU in its round-robin scheduling of
VCPUS.  When the second VCPU is mostly unused, FreeBSD runs a "pause"
instruction in its idle loop which only burns cycles without any
progress.  As soon as the timer tick expires, the first VCPU runs
the interrupt handler but very soon it sets it again---and QEMU
then goes back doing nothing in the second VCPU.

The fix is to make the pause instruction do "cpu_loop_exit".

Cc: Richard Henderson <rth@twiddle.net>
Reported-by: NLuigi Rizzo <rizzo@iet.unipi.it>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Message-id: 1384948442-24217-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@amazon.com>
      81f3053b
  15. 28 2月, 2013 1 次提交
  17. 20 2月, 2013 2 次提交
  19. 19 2月, 2013 4 次提交
  21. 19 12月, 2012 1 次提交
  23. 28 10月, 2012 1 次提交
  25. 01 10月, 2012 1 次提交
    • H
      x86: Implement SMEP and SMAP · a9321a4d
      由 H. Peter Anvin 提交于 
      This patch implements Supervisor Mode Execution Prevention (SMEP) and
Supervisor Mode Access Prevention (SMAP) for x86.  The purpose of the
patch, obviously, is to help kernel developers debug the support for
those features.

A fair bit of the code relates to the handling of CPUID features.  The
CPUID code probably would get greatly simplified if all the feature
bit words were unified into a single vector object, but in the
interest of producing a minimal patch for SMEP/SMAP, and because I had
very limited time for this project, I followed the existing style.

[ v2: don't change the definition of the qemu64 CPU shorthand, since
  that breaks loading old snapshots.  Per Anthony Liguori this can be
  fixed once the CPU feature set is snapshot.

  Change the coding style slightly to conform to checkpatch.pl. ]
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      a9321a4d
  27. 15 8月, 2012 8 次提交
  29. 29 6月, 2012 1 次提交
    • B
      x86: avoid AREG0 for exceptions · 77b2bc2c
      由 Blue Swirl 提交于 
      Add an explicit CPUX86State parameter instead of relying on AREG0.

Merge raise_exception_env() to raise_exception(), likewise with
raise_exception_err_env() and raise_exception_err().

Introduce cpu_svm_check_intercept_param() and cpu_vmexit()
as wrappers.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>
      77b2bc2c
  31. 11 1月, 2012 1 次提交
    • A
      target-i386: fix SSE rounding and flush to zero · 2355c16e
      由 Aurelien Jarno 提交于 
      SSE rounding and flush to zero control has never been implemented. However
given that softfloat-native was using a single state for FPU and SSE and
given that glibc is setting both FPU and SSE state in fesetround(), this
was working correctly up to the switch to softfloat.

Fix that by adding an update_sse_status() function similar to
update_fpu_status(), and callin git on write to mxcsr.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      2355c16e
  33. 23 10月, 2009 1 次提交
  35. 04 10月, 2009 1 次提交
    • A
      target-i386: add RDTSCP support · 1b050077
      由 Andre Przywara 提交于 
      RDTSCP reads the time stamp counter and atomically also the content
of a 32-bit MSR, which can be freely set by the OS. This allows CPU
local data to be queried by userspace.
Linux uses this to allow a fast implementation of the getcpu()
syscall, which uses the vsyscall page to avoid a context switch.
AMD CPUs since K8RevF and Intel CPUs since Nehalem support this
instruction.
RDTSCP is guarded by the RDTSCP CPUID bit (Fn8000_0001:EDX[27]).
Signed-off-by: NAndre Przywara <andre.przywara@amd.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      1b050077
  37. 22 5月, 2009 1 次提交
  39. 17 11月, 2008 1 次提交
  41. 26 9月, 2008 1 次提交
  43. 30 8月, 2008 1 次提交
  45. 18 6月, 2008 1 次提交
  47. 05 6月, 2008 1 次提交
  49. 04 6月, 2008 1 次提交
  51. 29 5月, 2008 1 次提交
  53. 23 5月, 2008 1 次提交
  55. 22 5月, 2008 1 次提交