1. 17 3月, 2015 1 次提交
  2. 17 12月, 2014 1 次提交
    • P
      KVM: PPC: Book3S HV: Remove code for PPC970 processors · c17b98cf
      Paul Mackerras 提交于
      This removes the code that was added to enable HV KVM to work
      on PPC970 processors.  The PPC970 is an old CPU that doesn't
      support virtualizing guest memory.  Removing PPC970 support also
      lets us remove the code for allocating and managing contiguous
      real-mode areas, the code for the !kvm->arch.using_mmu_notifiers
      case, the code for pinning pages of guest memory when first
      accessed and keeping track of which pages have been pinned, and
      the code for handling H_ENTER hypercalls in virtual mode.
      
      Book3S HV KVM is now supported only on POWER7 and POWER8 processors.
      The KVM_CAP_PPC_RMA capability now always returns 0.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      c17b98cf
  3. 28 7月, 2014 1 次提交
  4. 11 6月, 2014 1 次提交
    • M
      powerpc/book3s: Fix guest MC delivery mechanism to avoid soft lockups in guest. · 74845bc2
      Mahesh Salgaonkar 提交于
      Currently we forward MCEs to guest which have been recovered by guest.
      And for unhandled errors we do not deliver the MCE to guest. It looks like
      with no support of FWNMI in qemu, guest just panics whenever we deliver the
      recovered MCEs to guest. Also, the existig code used to return to host for
      unhandled errors which was casuing guest to hang with soft lockups inside
      guest and makes it difficult to recover guest instance.
      
      This patch now forwards all fatal MCEs to guest causing guest to crash/panic.
      And, for recovered errors we just go back to normal functioning of guest
      instead of returning to host. This fixes soft lockup issues in guest.
      This patch also fixes an issue where guest MCE events were not logged to
      host console.
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      74845bc2
  5. 05 12月, 2013 2 次提交
    • M
      powerpc/book3s: Decode and save machine check event. · 36df96f8
      Mahesh Salgaonkar 提交于
      Now that we handle machine check in linux, the MCE decoding should also
      take place in linux host. This info is crucial to log before we go down
      in case we can not handle the machine check errors. This patch decodes
      and populates a machine check event which contain high level meaning full
      MCE information.
      
      We do this in real mode C code with ME bit on. The MCE information is still
      available on emergency stack (in pt_regs structure format). Even if we take
      another exception at this point the MCE early handler will allocate a new
      stack frame on top of current one. So when we return back here we still have
      our MCE information safe on current stack.
      
      We use per cpu buffer to save high level MCE information. Each per cpu buffer
      is an array of machine check event structure indexed by per cpu counter
      mce_nest_count. The mce_nest_count is incremented every time we enter
      machine check early handler in real mode to get the current free slot
      (index = mce_nest_count - 1). The mce_nest_count is decremented once the
      MCE info is consumed by virtual mode machine exception handler.
      
      This patch provides save_mce_event(), get_mce_event() and release_mce_event()
      generic routines that can be used by machine check handlers to populate and
      retrieve the event. The routine release_mce_event() will free the event slot so
      that it can be reused. Caller can invoke get_mce_event() with a release flag
      either to release the event slot immediately OR keep it so that it can be
      fetched again. The event slot can be also released anytime by invoking
      release_mce_event().
      
      This patch also updates kvm code to invoke get_mce_event to retrieve generic
      mce event rather than paca->opal_mce_evt.
      
      The KVM code always calls get_mce_event() with release flags set to false so
      that event is available for linus host machine
      
      If machine check occurs while we are in guest, KVM tries to handle the error.
      If KVM is able to handle MC error successfully, it enters the guest and
      delivers the machine check to guest. If KVM is not able to handle MC error, it
      exists the guest and passes the control to linux host machine check handler
      which then logs MC event and decides how to handle it in linux host. In failure
      case, KVM needs to make sure that the MC event is available for linux host to
      consume. Hence KVM always calls get_mce_event() with release flags set to false
      and later it invokes release_mce_event() only if it succeeds to handle error.
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      36df96f8
    • M
      powerpc/book3s: Add flush_tlb operation in cpu_spec. · 04407050
      Mahesh Salgaonkar 提交于
      This patch introduces flush_tlb operation in cpu_spec structure. This will
      help us to invoke appropriate CPU-side flush tlb routine. This patch
      adds the foundation to invoke CPU specific flush routine for respective
      architectures. Currently this patch introduce flush_tlb for p7 and p8.
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      04407050
  6. 06 1月, 2013 1 次提交
  7. 06 12月, 2012 1 次提交
    • P
      KVM: PPC: Book3S HV: Handle guest-caused machine checks on POWER7 without panicking · b4072df4
      Paul Mackerras 提交于
      Currently, if a machine check interrupt happens while we are in the
      guest, we exit the guest and call the host's machine check handler,
      which tends to cause the host to panic.  Some machine checks can be
      triggered by the guest; for example, if the guest creates two entries
      in the SLB that map the same effective address, and then accesses that
      effective address, the CPU will take a machine check interrupt.
      
      To handle this better, when a machine check happens inside the guest,
      we call a new function, kvmppc_realmode_machine_check(), while still in
      real mode before exiting the guest.  On POWER7, it handles the cases
      that the guest can trigger, either by flushing and reloading the SLB,
      or by flushing the TLB, and then it delivers the machine check interrupt
      directly to the guest without going back to the host.  On POWER7, the
      OPAL firmware patches the machine check interrupt vector so that it
      gets control first, and it leaves behind its analysis of the situation
      in a structure pointed to by the opal_mc_evt field of the paca.  The
      kvmppc_realmode_machine_check() function looks at this, and if OPAL
      reports that there was no error, or that it has handled the error, we
      also go straight back to the guest with a machine check.  We have to
      deliver a machine check to the guest since the machine check interrupt
      might have trashed valid values in SRR0/1.
      
      If the machine check is one we can't handle in real mode, and one that
      OPAL hasn't already handled, or on PPC970, we exit the guest and call
      the host's machine check handler.  We do this by jumping to the
      machine_check_fwnmi label, rather than absolute address 0x200, because
      we don't want to re-execute OPAL's handler on POWER7.  On PPC970, the
      two are equivalent because address 0x200 just contains a branch.
      
      Then, if the host machine check handler decides that the system can
      continue executing, kvmppc_handle_exit() delivers a machine check
      interrupt to the guest -- once again to let the guest know that SRR0/1
      have been modified.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      [agraf: fix checkpatch warnings]
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      b4072df4