1. 10 6月, 2016 12 次提交
  2. 13 5月, 2016 1 次提交
    • C
      KVM: halt_polling: provide a way to qualify wakeups during poll · 3491caf2
      Christian Borntraeger 提交于
      Some wakeups should not be considered a sucessful poll. For example on
      s390 I/O interrupts are usually floating, which means that _ALL_ CPUs
      would be considered runnable - letting all vCPUs poll all the time for
      transactional like workload, even if one vCPU would be enough.
      This can result in huge CPU usage for large guests.
      This patch lets architectures provide a way to qualify wakeups if they
      should be considered a good/bad wakeups in regard to polls.
      
      For s390 the implementation will fence of halt polling for anything but
      known good, single vCPU events. The s390 implementation for floating
      interrupts does a wakeup for one vCPU, but the interrupt will be delivered
      by whatever CPU checks first for a pending interrupt. We prefer the
      woken up CPU by marking the poll of this CPU as "good" poll.
      This code will also mark several other wakeup reasons like IPI or
      expired timers as "good". This will of course also mark some events as
      not sucessful. As  KVM on z runs always as a 2nd level hypervisor,
      we prefer to not poll, unless we are really sure, though.
      
      This patch successfully limits the CPU usage for cases like uperf 1byte
      transactional ping pong workload or wakeup heavy workload like OLTP
      while still providing a proper speedup.
      
      This also introduced a new vcpu stat "halt_poll_no_tuning" that marks
      wakeups that are considered not good for polling.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: Radim Krčmář <rkrcmar@redhat.com> (for an earlier version)
      Cc: David Matlack <dmatlack@google.com>
      Cc: Wanpeng Li <kernellwp@gmail.com>
      [Rename config symbol. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3491caf2
  3. 09 5月, 2016 6 次提交
  4. 08 3月, 2016 10 次提交
  5. 10 2月, 2016 10 次提交
  6. 26 1月, 2016 1 次提交
    • D
      KVM: s390: fix memory overwrites when vx is disabled · 9abc2a08
      David Hildenbrand 提交于
      The kernel now always uses vector registers when available, however KVM
      has special logic if support is really enabled for a guest. If support
      is disabled, guest_fpregs.fregs will only contain memory for the fpu.
      The kernel, however, will store vector registers into that area,
      resulting in crazy memory overwrites.
      
      Simply extending that area is not enough, because the format of the
      registers also changes. We would have to do additional conversions, making
      the code even more complex. Therefore let's directly use one place for
      the vector/fpu registers + fpc (in kvm_run). We just have to convert the
      data properly when accessing it. This makes current code much easier.
      
      Please note that vector/fpu registers are now always stored to
      vcpu->run->s.regs.vrs. Although this data is visible to QEMU and
      used for migration, we only guarantee valid values to user space  when
      KVM_SYNC_VRS is set. As that is only the case when we have vector
      register support, we are on the safe side.
      
      Fixes: b5510d9b ("s390/fpu: always enable the vector facility if it is available")
      Cc: stable@vger.kernel.org # v4.4 d9a3a09a s390/kvm: remove dependency on struct save_area definition
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      [adopt to d9a3a09a]
      9abc2a08