1. 05 5月, 2013 1 次提交
  2. 02 5月, 2013 1 次提交
    • P
      KVM: PPC: Book3S: Add API for in-kernel XICS emulation · 5975a2e0
      Paul Mackerras 提交于
      This adds the API for userspace to instantiate an XICS device in a VM
      and connect VCPUs to it.  The API consists of a new device type for
      the KVM_CREATE_DEVICE ioctl, a new capability KVM_CAP_IRQ_XICS, which
      functions similarly to KVM_CAP_IRQ_MPIC, and the KVM_IRQ_LINE ioctl,
      which is used to assert and deassert interrupt inputs of the XICS.
      
      The XICS device has one attribute group, KVM_DEV_XICS_GRP_SOURCES.
      Each attribute within this group corresponds to the state of one
      interrupt source.  The attribute number is the same as the interrupt
      source number.
      
      This does not support irq routing or irqfd yet.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      5975a2e0
  3. 27 4月, 2013 6 次提交
  4. 17 4月, 2013 2 次提交
  5. 16 4月, 2013 1 次提交
  6. 08 4月, 2013 2 次提交
  7. 07 4月, 2013 1 次提交
  8. 11 3月, 2013 2 次提交
  9. 06 3月, 2013 1 次提交
  10. 05 3月, 2013 5 次提交
  11. 11 2月, 2013 1 次提交
  12. 05 2月, 2013 2 次提交
    • T
      KVM: set_memory_region: Disallow changing read-only attribute later · 75d61fbc
      Takuya Yoshikawa 提交于
      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: NGleb Natapov <gleb@redhat.com>
      Signed-off-by: NTakuya 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: NMarcelo Tosatti <mtosatti@redhat.com>
      75d61fbc
    • T
      KVM: set_memory_region: Identify the requested change explicitly · f64c0398
      Takuya Yoshikawa 提交于
      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: NTakuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      f64c0398
  13. 29 1月, 2013 2 次提交
    • R
      kvm: Handle yield_to failure return code for potential undercommit case · c45c528e
      Raghavendra K T 提交于
      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: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: NRaghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Tested-by: NChegu Vinod <chegu_vinod@hp.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      c45c528e
    • Y
      x86, apicv: add virtual interrupt delivery support · c7c9c56c
      Yang Zhang 提交于
      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: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NKevin Tian <kevin.tian@intel.com>
      Signed-off-by: NYang Zhang <yang.z.zhang@Intel.com>
      Signed-off-by: NGleb Natapov <gleb@redhat.com>
      c7c9c56c
  14. 27 1月, 2013 1 次提交
  15. 17 1月, 2013 3 次提交
  16. 14 1月, 2013 1 次提交
  17. 24 12月, 2012 1 次提交
  18. 23 12月, 2012 1 次提交
  19. 14 12月, 2012 6 次提交