1. 17 Oct, 2013 11 commits
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Add support for guest Program Priority Register · 4b8473c9
      Paul Mackerras authored
      POWER7 and later IBM server processors have a register called the
      Program Priority Register (PPR), which controls the priority of
      each hardware CPU SMT thread, and affects how fast it runs compared
      to other SMT threads.  This priority can be controlled by writing to
      the PPR or by use of a set of instructions of the form or rN,rN,rN
      which are otherwise no-ops but have been defined to set the priority
      to particular levels.
      
      This adds code to context switch the PPR when entering and exiting
      guests and to make the PPR value accessible through the SET/GET_ONE_REG
      interface.  When entering the guest, we set the PPR as late as
      possible, because if we are setting a low thread priority it will
      make the code run slowly from that point on.  Similarly, the
      first-level interrupt handlers save the PPR value in the PACA very
      early on, and set the thread priority to the medium level, so that
      the interrupt handling code runs at a reasonable speed.
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      4b8473c9
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Store LPCR value for each virtual core · a0144e2a
      Paul Mackerras authored
      This adds the ability to have a separate LPCR (Logical Partitioning
      Control Register) value relating to a guest for each virtual core,
      rather than only having a single value for the whole VM.  This
      corresponds to what real POWER hardware does, where there is a LPCR
      per CPU thread but most of the fields are required to have the same
      value on all active threads in a core.
      
      The per-virtual-core LPCR can be read and written using the
      GET/SET_ONE_REG interface.  Userspace can can only modify the
      following fields of the LPCR value:
      
      DPFD	Default prefetch depth
      ILE	Interrupt little-endian
      TC	Translation control (secondary HPT hash group search disable)
      
      We still maintain a per-VM default LPCR value in kvm->arch.lpcr, which
      contains bits relating to memory management, i.e. the Virtualized
      Partition Memory (VPM) bits and the bits relating to guest real mode.
      When this default value is updated, the update needs to be propagated
      to the per-vcore values, so we add a kvmppc_update_lpcr() helper to do
      that.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      [agraf: fix whitespace]
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      a0144e2a
    • Paul Mackerras's avatar
      KVM: PPC: BookE: Add GET/SET_ONE_REG interface for VRSAVE · 8b75cbbe
      Paul Mackerras authored
      This makes the VRSAVE register value for a vcpu accessible through
      the GET/SET_ONE_REG interface on Book E systems (in addition to the
      existing GET/SET_SREGS interface), for consistency with Book 3S.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      8b75cbbe
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Avoid unbalanced increments of VPA yield count · 8c2dbb79
      Paul Mackerras authored
      The yield count in the VPA is supposed to be incremented every time
      we enter the guest, and every time we exit the guest, so that its
      value is even when the vcpu is running in the guest and odd when it
      isn't.  However, it's currently possible that we increment the yield
      count on the way into the guest but then find that other CPU threads
      are already exiting the guest, so we go back to nap mode via the
      secondary_too_late label.  In this situation we don't increment the
      yield count again, breaking the relationship between the LSB of the
      count and whether the vcpu is in the guest.
      
      To fix this, we move the increment of the yield count to a point
      after we have checked whether other CPU threads are exiting.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      8c2dbb79
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Pull out interrupt-reading code into a subroutine · c934243c
      Paul Mackerras authored
      This moves the code in book3s_hv_rmhandlers.S that reads any pending
      interrupt from the XICS interrupt controller, and works out whether
      it is an IPI for the guest, an IPI for the host, or a device interrupt,
      into a new function called kvmppc_read_intr.  Later patches will
      need this.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      c934243c
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Restructure kvmppc_hv_entry to be a subroutine · 218309b7
      Paul Mackerras authored
      We have two paths into and out of the low-level guest entry and exit
      code: from a vcpu task via kvmppc_hv_entry_trampoline, and from the
      system reset vector for an offline secondary thread on POWER7 via
      kvm_start_guest.  Currently both just branch to kvmppc_hv_entry to
      enter the guest, and on guest exit, we test the vcpu physical thread
      ID to detect which way we came in and thus whether we should return
      to the vcpu task or go back to nap mode.
      
      In order to make the code flow clearer, and to keep the code relating
      to each flow together, this turns kvmppc_hv_entry into a subroutine
      that follows the normal conventions for call and return.  This means
      that kvmppc_hv_entry_trampoline() and kvmppc_hv_entry() now establish
      normal stack frames, and we use the normal stack slots for saving
      return addresses rather than local_paca->kvm_hstate.vmhandler.  Apart
      from that this is mostly moving code around unchanged.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      218309b7
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Implement H_CONFER · 42d7604d
      Paul Mackerras authored
      The H_CONFER hypercall is used when a guest vcpu is spinning on a lock
      held by another vcpu which has been preempted, and the spinning vcpu
      wishes to give its timeslice to the lock holder.  We implement this
      in the straightforward way using kvm_vcpu_yield_to().
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      42d7604d
    • Paul Mackerras's avatar
      KVM: PPC: Book3S: Add GET/SET_ONE_REG interface for VRSAVE · c0867fd5
      Paul Mackerras authored
      The VRSAVE register value for a vcpu is accessible through the
      GET/SET_SREGS interface for Book E processors, but not for Book 3S
      processors.  In order to make this accessible for Book 3S processors,
      this adds a new register identifier for GET/SET_ONE_REG, and adds
      the code to implement it.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      c0867fd5
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Implement timebase offset for guests · 93b0f4dc
      Paul Mackerras authored
      This allows guests to have a different timebase origin from the host.
      This is needed for migration, where a guest can migrate from one host
      to another and the two hosts might have a different timebase origin.
      However, the timebase seen by the guest must not go backwards, and
      should go forwards only by a small amount corresponding to the time
      taken for the migration.
      
      Therefore this provides a new per-vcpu value accessed via the one_reg
      interface using the new KVM_REG_PPC_TB_OFFSET identifier.  This value
      defaults to 0 and is not modified by KVM.  On entering the guest, this
      value is added onto the timebase, and on exiting the guest, it is
      subtracted from the timebase.
      
      This is only supported for recent POWER hardware which has the TBU40
      (timebase upper 40 bits) register.  Writing to the TBU40 register only
      alters the upper 40 bits of the timebase, leaving the lower 24 bits
      unchanged.  This provides a way to modify the timebase for guest
      migration without disturbing the synchronization of the timebase
      registers across CPU cores.  The kernel rounds up the value given
      to a multiple of 2^24.
      
      Timebase values stored in KVM structures (struct kvm_vcpu, struct
      kvmppc_vcore, etc.) are stored as host timebase values.  The timebase
      values in the dispatch trace log need to be guest timebase values,
      however, since that is read directly by the guest.  This moves the
      setting of vcpu->arch.dec_expires on guest exit to a point after we
      have restored the host timebase so that vcpu->arch.dec_expires is a
      host timebase value.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      93b0f4dc
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore SIAR and SDAR along with other PMU registers · 14941789
      Paul Mackerras authored
      Currently we are not saving and restoring the SIAR and SDAR registers in
      the PMU (performance monitor unit) on guest entry and exit.  The result
      is that performance monitoring tools in the guest could get false
      information about where a program was executing and what data it was
      accessing at the time of a performance monitor interrupt.  This fixes
      it by saving and restoring these registers along with the other PMU
      registers on guest entry/exit.
      
      This also provides a way for userspace to access these values for a
      vcpu via the one_reg interface.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      14941789
    • Michael Neuling's avatar
      KVM: PPC: Book3S HV: Reserve POWER8 space in get/set_one_reg · 3b783474
      Michael Neuling authored
      This reserves space in get/set_one_reg ioctl for the extra guest state
      needed for POWER8.  It doesn't implement these at all, it just reserves
      them so that the ABI is defined now.
      
      A few things to note here:
      
      - This add *a lot* state for transactional memory.  TM suspend mode,
        this is unavoidable, you can't simply roll back all transactions and
        store only the checkpointed state.  I've added this all to
        get/set_one_reg (including GPRs) rather than creating a new ioctl
        which returns a struct kvm_regs like KVM_GET_REGS does.  This means we
        if we need to extract the TM state, we are going to need a bucket load
        of IOCTLs.  Hopefully most of the time this will not be needed as we
        can look at the MSR to see if TM is active and only grab them when
        needed.  If this becomes a bottle neck in future we can add another
        ioctl to grab all this state in one go.
      
      - The TM state is offset by 0x80000000.
      
      - For TM, I've done away with VMX and FP and created a single 64x128 bit
        VSX register space.
      
      - I've left a space of 1 (at 0x9c) since Paulus needs to add a value
        which applies to POWER7 as well.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      3b783474
  2. 16 Oct, 2013 2 commits
  3. 15 Oct, 2013 1 commit
  4. 14 Oct, 2013 7 commits
  5. 13 Oct, 2013 3 commits
  6. 10 Oct, 2013 1 commit
  7. 03 Oct, 2013 8 commits
  8. 02 Oct, 2013 5 commits
  9. 30 Sep, 2013 2 commits
    • Paolo Bonzini's avatar
      KVM: Convert kvm_lock back to non-raw spinlock · 2f303b74
      Paolo Bonzini authored
      In commit e935b837 ("KVM: Convert kvm_lock to raw_spinlock"),
      the kvm_lock was made a raw lock.  However, the kvm mmu_shrink()
      function tries to grab the (non-raw) mmu_lock within the scope of
      the raw locked kvm_lock being held.  This leads to the following:
      
      BUG: sleeping function called from invalid context at kernel/rtmutex.c:659
      in_atomic(): 1, irqs_disabled(): 0, pid: 55, name: kswapd0
      Preemption disabled at:[<ffffffffa0376eac>] mmu_shrink+0x5c/0x1b0 [kvm]
      
      Pid: 55, comm: kswapd0 Not tainted 3.4.34_preempt-rt
      Call Trace:
       [<ffffffff8106f2ad>] __might_sleep+0xfd/0x160
       [<ffffffff817d8d64>] rt_spin_lock+0x24/0x50
       [<ffffffffa0376f3c>] mmu_shrink+0xec/0x1b0 [kvm]
       [<ffffffff8111455d>] shrink_slab+0x17d/0x3a0
       [<ffffffff81151f00>] ? mem_cgroup_iter+0x130/0x260
       [<ffffffff8111824a>] balance_pgdat+0x54a/0x730
       [<ffffffff8111fe47>] ? set_pgdat_percpu_threshold+0xa7/0xd0
       [<ffffffff811185bf>] kswapd+0x18f/0x490
       [<ffffffff81070961>] ? get_parent_ip+0x11/0x50
       [<ffffffff81061970>] ? __init_waitqueue_head+0x50/0x50
       [<ffffffff81118430>] ? balance_pgdat+0x730/0x730
       [<ffffffff81060d2b>] kthread+0xdb/0xe0
       [<ffffffff8106e122>] ? finish_task_switch+0x52/0x100
       [<ffffffff817e1e94>] kernel_thread_helper+0x4/0x10
       [<ffffffff81060c50>] ? __init_kthread_worker+0x
      
      After the previous patch, kvm_lock need not be a raw spinlock anymore,
      so change it back.
      Reported-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: kvm@vger.kernel.org
      Cc: gleb@redhat.com
      Cc: jan.kiszka@siemens.com
      Reviewed-by: default avatarGleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      2f303b74
    • Paolo Bonzini's avatar
      KVM: protect kvm_usage_count with its own spinlock · 4a937f96
      Paolo Bonzini authored
      The VM list need not be protected by a raw spinlock.  Separate the
      two so that kvm_lock can be made non-raw.
      
      Cc: kvm@vger.kernel.org
      Cc: gleb@redhat.com
      Cc: jan.kiszka@siemens.com
      Reviewed-by: default avatarGleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4a937f96