1. 08 Apr, 2013 2 commits
  2. 11 Mar, 2013 2 commits
  3. 05 Mar, 2013 1 commit
  4. 04 Mar, 2013 5 commits
  5. 11 Feb, 2013 1 commit
  6. 04 Feb, 2013 2 commits
    • Takuya Yoshikawa's avatar
      KVM: set_memory_region: Disallow changing read-only attribute later · 75d61fbc
      Takuya Yoshikawa authored
      
      
      As Xiao pointed out, there are a few problems with it:
       - kvm_arch_commit_memory_region() write protects the memory slot only
         for GET_DIRTY_LOG when modifying the flags.
       - FNAME(sync_page) uses the old spte value to set a new one without
         checking KVM_MEM_READONLY flag.
      
      Since we flush all shadow pages when creating a new slot, the simplest
      fix is to disallow such problematic flag changes: this is safe because
      no one is doing such things.
      
      Reviewed-by: default avatarGleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarTakuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
      Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      75d61fbc
    • Takuya Yoshikawa's avatar
      KVM: set_memory_region: Identify the requested change explicitly · f64c0398
      Takuya Yoshikawa authored
      
      
      KVM_SET_USER_MEMORY_REGION forces __kvm_set_memory_region() to identify
      what kind of change is being requested by checking the arguments.  The
      current code does this checking at various points in code and each
      condition being used there is not easy to understand at first glance.
      
      This patch consolidates these checks and introduces an enum to name the
      possible changes to clean up the code.
      
      Although this does not introduce any functional changes, there is one
      change which optimizes the code a bit: if we have nothing to change, the
      new code returns 0 immediately.
      
      Note that the return value for this case cannot be changed since QEMU
      relies on it: we noticed this when we changed it to -EINVAL and got a
      section mismatch error at the final stage of live migration.
      
      Signed-off-by: default avatarTakuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      f64c0398
  7. 29 Jan, 2013 2 commits
    • Raghavendra K T's avatar
      kvm: Handle yield_to failure return code for potential undercommit case · c45c528e
      Raghavendra K T authored
      
      
      yield_to returns -ESRCH, When source and target of yield_to
      run queue length is one. When we see three successive failures of
      yield_to we assume we are in potential undercommit case and abort
      from PLE handler.
      The assumption is backed by low probability of wrong decision
      for even worst case scenarios such as average runqueue length
      between 1 and 2.
      
      More detail on rationale behind using three tries:
      if p is the probability of finding rq length one on a particular cpu,
      and if we do n tries, then probability of exiting ple handler is:
      
       p^(n+1) [ because we would have come across one source with rq length
      1 and n target cpu rqs  with length 1 ]
      
      so
      num tries:         probability of aborting ple handler (1.5x overcommit)
       1                 1/4
       2                 1/8
       3                 1/16
      
      We can increase this probability with more tries, but the problem is
      the overhead.
      Also, If we have tried three times that means we would have iterated
      over 3 good eligible vcpus along with many non-eligible candidates. In
      worst case if we iterate all the vcpus, we reduce 1x performance and
      overcommit performance get hit.
      
      note that we do not update last boosted vcpu in failure cases.
      Thank Avi for raising question on aborting after first fail from yield_to.
      
      Reviewed-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: default avatarRaghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Tested-by: default avatarChegu Vinod <chegu_vinod@hp.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      c45c528e
    • Yang Zhang's avatar
      x86, apicv: add virtual interrupt delivery support · c7c9c56c
      Yang Zhang authored
      
      
      Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
      manually, which is fully taken care of by the hardware. This needs
      some special awareness into existing interrupr injection path:
      
      - for pending interrupt, instead of direct injection, we may need
        update architecture specific indicators before resuming to guest.
      
      - A pending interrupt, which is masked by ISR, should be also
        considered in above update action, since hardware will decide
        when to inject it at right time. Current has_interrupt and
        get_interrupt only returns a valid vector from injection p.o.v.
      
      Reviewed-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarKevin Tian <kevin.tian@intel.com>
      Signed-off-by: default avatarYang Zhang <yang.z.zhang@Intel.com>
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      c7c9c56c
  8. 27 Jan, 2013 1 commit
  9. 17 Jan, 2013 3 commits
  10. 14 Jan, 2013 1 commit
  11. 24 Dec, 2012 1 commit
  12. 23 Dec, 2012 1 commit
  13. 13 Dec, 2012 7 commits
  14. 29 Nov, 2012 1 commit
    • Alex Williamson's avatar
      KVM: Fix user memslot overlap check · 5419369e
      Alex Williamson authored
      
      
      Prior to memory slot sorting this loop compared all of the user memory
      slots for overlap with new entries.  With memory slot sorting, we're
      just checking some number of entries in the array that may or may not
      be user slots.  Instead, walk all the slots with kvm_for_each_memslot,
      which has the added benefit of terminating early when we hit the first
      empty slot, and skip comparison to private slots.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      5419369e
  15. 27 Nov, 2012 2 commits
    • Marcelo Tosatti's avatar
      KVM: x86: add kvm_arch_vcpu_postcreate callback, move TSC initialization · 42897d86
      Marcelo Tosatti authored
      
      
      TSC initialization will soon make use of online_vcpus.
      
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      42897d86
    • Marcelo Tosatti's avatar
      KVM: x86: implement PVCLOCK_TSC_STABLE_BIT pvclock flag · d828199e
      Marcelo Tosatti authored
      
      
      KVM added a global variable to guarantee monotonicity in the guest.
      One of the reasons for that is that the time between
      
      	1. ktime_get_ts(&timespec);
      	2. rdtscll(tsc);
      
      Is variable. That is, given a host with stable TSC, suppose that
      two VCPUs read the same time via ktime_get_ts() above.
      
      The time required to execute 2. is not the same on those two instances
      executing in different VCPUS (cache misses, interrupts...).
      
      If the TSC value that is used by the host to interpolate when
      calculating the monotonic time is the same value used to calculate
      the tsc_timestamp value stored in the pvclock data structure, and
      a single <system_timestamp, tsc_timestamp> tuple is visible to all
      vcpus simultaneously, this problem disappears. See comment on top
      of pvclock_update_vm_gtod_copy for details.
      
      Monotonicity is then guaranteed by synchronicity of the host TSCs
      and guest TSCs.
      
      Set TSC stable pvclock flag in that case, allowing the guest to read
      clock from userspace.
      
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      d828199e
  16. 13 Nov, 2012 2 commits
  17. 29 Oct, 2012 1 commit
  18. 22 Oct, 2012 1 commit
  19. 05 Oct, 2012 1 commit
  20. 17 Sep, 2012 1 commit
    • Michael S. Tsirkin's avatar
      KVM: make processes waiting on vcpu mutex killable · 9fc77441
      Michael S. Tsirkin authored
      
      
      vcpu mutex can be held for unlimited time so
      taking it with mutex_lock on an ioctl is wrong:
      one process could be passed a vcpu fd and
      call this ioctl on the vcpu used by another process,
      it will then be unkillable until the owner exits.
      
      Call mutex_lock_killable instead and return status.
      Note: mutex_lock_interruptible would be even nicer,
      but I am not sure all users are prepared to handle EINTR
      from these ioctls. They might misinterpret it as an error.
      
      Cleanup paths expect a vcpu that can't be used by
      any userspace so this will always succeed - catch bugs
      by calling BUG_ON.
      
      Catch callers that don't check return state by adding
      __must_check.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      9fc77441
  21. 06 Sep, 2012 2 commits