1. 11 6月, 2014 4 次提交
  2. 07 6月, 2014 2 次提交
  3. 06 6月, 2014 1 次提交
    • M
      powerpc/mm: Check paca psize is up to date for huge mappings · 09567e7f
      Michael Ellerman 提交于
      We have a bug in our hugepage handling which exhibits as an infinite
      loop of hash faults. If the fault is being taken in the kernel it will
      typically trigger the softlockup detector, or the RCU stall detector.
      
      The bug is as follows:
      
       1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
       2. Slice code converts the slice psize to 16M.
       3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
          synchronises the mm->context with the paca->context. So the paca slice
          mask is updated to include the 16M slice.
       3. Either:
          * mmap() fails because there are no huge pages available.
          * mmap() succeeds and the mapping is then munmapped.
          In both cases the slice psize remains at 16M in both the paca & mm.
       4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
       5. The slice psize is converted back to 64K. Because of the check on line 539
          of slice.c we DO NOT update the paca->context. The paca slice mask is now
          out of sync with the mm slice mask.
       6. User/kernel accesses 0xa0000000.
       7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
          to create an SLB entry and inserts it in the SLB.
      18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
          is found so a data access exception is generated.
      19. The data access handler calls do_page_fault() -> handle_mm_fault().
      10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
      11. The hardware retries the access, there is still nothing in the hash table
          so once again a data access exception is generated.
      12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
          hash. Although the THP mapping maps 16M the hashing is done using 64K
          as the segment page size.
      13. hash_page() returns immediately after calling __hash_page_thp(), skipping
          over the code at line 1125. Resulting in the mismatch between the
          paca->context and mm->context not being detected.
      14. The hardware retries the access, the hash it generates using the 16M
          SLB entry does NOT match the hash we inserted.
      15. We take another data access and go into __hash_page_thp().
      16. We see a valid entry in the hpte_slot_array and so we call updatepp()
          which succeeds.
      17. Goto 14.
      
      We could fix this in two ways. The first would be to remove or modify
      the check on line 539 of slice.c.
      
      The second option is to cause the check of paca psize in hash_page() on
      line 1125 to also be done for THP pages.
      
      We prefer the latter, because the check & update of the paca psize is
      not done until we know it's necessary. It's also done only on the
      current cpu, so we don't need to IPI all other cpus.
      
      Without further rearranging the code, the simplest fix is to pull out
      the code that checks paca psize and call it in two places. Firstly for
      THP/hugetlb, and secondly for other mappings as before.
      
      Thanks to Dave Jones for trinity, which originally found this bug.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: stable@vger.kernel.org [v3.11+]
      09567e7f
  4. 05 6月, 2014 16 次提交
  5. 02 6月, 2014 1 次提交
  6. 30 5月, 2014 16 次提交
    • A
      KVM: PPC: Book3S PR: Rework SLB switching code · d8d164a9
      Alexander Graf 提交于
      On LPAR guest systems Linux enables the shadow SLB to indicate to the
      hypervisor a number of SLB entries that always have to be available.
      
      Today we go through this shadow SLB and disable all ESID's valid bits.
      However, pHyp doesn't like this approach very much and honors us with
      fancy machine checks.
      
      Fortunately the shadow SLB descriptor also has an entry that indicates
      the number of valid entries following. During the lifetime of a guest
      we can just swap that value to 0 and don't have to worry about the
      SLB restoration magic.
      
      While we're touching the code, let's also make it more readable (get
      rid of rldicl), allow it to deal with a dynamic number of bolted
      SLB entries and only do shadow SLB swizzling on LPAR systems.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      d8d164a9
    • A
      KVM: PPC: Book3S PR: Use SLB entry 0 · 207438d4
      Alexander Graf 提交于
      We didn't make use of SLB entry 0 because ... of no good reason. SLB entry 0
      will always be used by the Linux linear SLB entry, so the fact that slbia
      does not invalidate it doesn't matter as we overwrite SLB 0 on exit anyway.
      
      Just enable use of SLB entry 0 for our shadow SLB code.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      207438d4
    • P
      KVM: PPC: Book3S HV: Fix machine check delivery to guest · 000a25dd
      Paul Mackerras 提交于
      The code that delivered a machine check to the guest after handling
      it in real mode failed to load up r11 before calling kvmppc_msr_interrupt,
      which needs the old MSR value in r11 so it can see the transactional
      state there.  This adds the missing load.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      000a25dd
    • P
      KVM: PPC: Book3S HV: Work around POWER8 performance monitor bugs · 9bc01a9b
      Paul Mackerras 提交于
      This adds workarounds for two hardware bugs in the POWER8 performance
      monitor unit (PMU), both related to interrupt generation.  The effect
      of these bugs is that PMU interrupts can get lost, leading to tools
      such as perf reporting fewer counts and samples than they should.
      
      The first bug relates to the PMAO (perf. mon. alert occurred) bit in
      MMCR0; setting it should cause an interrupt, but doesn't.  The other
      bug relates to the PMAE (perf. mon. alert enable) bit in MMCR0.
      Setting PMAE when a counter is negative and counter negative
      conditions are enabled to cause alerts should cause an alert, but
      doesn't.
      
      The workaround for the first bug is to create conditions where a
      counter will overflow, whenever we are about to restore a MMCR0
      value that has PMAO set (and PMAO_SYNC clear).  The workaround for
      the second bug is to freeze all counters using MMCR2 before reading
      MMCR0.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      9bc01a9b
    • P
      KVM: PPC: Book3S HV: Make sure we don't miss dirty pages · 6c576e74
      Paul Mackerras 提交于
      Current, when testing whether a page is dirty (when constructing the
      bitmap for the KVM_GET_DIRTY_LOG ioctl), we test the C (changed) bit
      in the HPT entries mapping the page, and if it is 0, we consider the
      page to be clean.  However, the Power ISA doesn't require processors
      to set the C bit to 1 immediately when writing to a page, and in fact
      allows them to delay the writeback of the C bit until they receive a
      TLB invalidation for the page.  Thus it is possible that the page
      could be dirty and we miss it.
      
      Now, if there are vcpus running, this is not serious since the
      collection of the dirty log is racy already - some vcpu could dirty
      the page just after we check it.  But if there are no vcpus running we
      should return definitive results, in case we are in the final phase of
      migrating the guest.
      
      Also, if the permission bits in the HPTE don't allow writing, then we
      know that no CPU can set C.  If the HPTE was previously writable and
      the page was modified, any C bit writeback would have been flushed out
      by the tlbie that we did when changing the HPTE to read-only.
      
      Otherwise we need to do a TLB invalidation even if the C bit is 0, and
      then check the C bit.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      6c576e74
    • A
      KVM: PPC: Book3S HV: Fix dirty map for hugepages · 687414be
      Alexey Kardashevskiy 提交于
      The dirty map that we construct for the KVM_GET_DIRTY_LOG ioctl has
      one bit per system page (4K/64K).  Currently, we only set one bit in
      the map for each HPT entry with the Change bit set, even if the HPT is
      for a large page (e.g., 16MB).  Userspace then considers only the
      first system page dirty, though in fact the guest may have modified
      anywhere in the large page.
      
      To fix this, we make kvm_test_clear_dirty() return the actual number
      of pages that are dirty (and rename it to kvm_test_clear_dirty_npages()
      to emphasize that that's what it returns).  In kvmppc_hv_get_dirty_log()
      we then set that many bits in the dirty map.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      687414be
    • P
      KVM: PPC: Book3S HV: Put huge-page HPTEs in rmap chain for base address · 1066f772
      Paul Mackerras 提交于
      Currently, when a huge page is faulted in for a guest, we select the
      rmap chain to insert the HPTE into based on the guest physical address
      that the guest tried to access.  Since there is an rmap chain for each
      system page, there are many rmap chains for the area covered by a huge
      page (e.g. 256 for 16MB pages when PAGE_SIZE = 64kB), and the huge-page
      HPTE could end up in any one of them.
      
      For consistency, and to make the huge-page HPTEs easier to find, we now
      put huge-page HPTEs in the rmap chain corresponding to the base address
      of the huge page.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      1066f772
    • P
      KVM: PPC: Book3S HV: Fix check for running inside guest in global_invalidates() · 55765483
      Paul Mackerras 提交于
      The global_invalidates() function contains a check that is intended
      to tell whether we are currently executing in the context of a hypercall
      issued by the guest.  The reason is that the optimization of using a
      local TLB invalidate instruction is only valid in that context.  The
      check was testing local_paca->kvm_hstate.kvm_vcore, which gets set
      when entering the guest but no longer gets cleared when exiting the
      guest.  To fix this, we use the kvm_vcpu field instead, which does
      get cleared when exiting the guest, by the kvmppc_release_hwthread()
      calls inside kvmppc_run_core().
      
      The effect of having the check wrong was that when kvmppc_do_h_remove()
      got called from htab_write() on the destination machine during a
      migration, it cleared the current cpu's bit in kvm->arch.need_tlb_flush.
      This meant that when the guest started running in the destination VM,
      it may miss out on doing a complete TLB flush, and therefore may end
      up using stale TLB entries from a previous guest that used the same
      LPID value.
      
      This should make migration more reliable.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      55765483
    • P
      KVM: PPC: Book3S: Move KVM_REG_PPC_WORT to an unused register number · e1d8a96d
      Paul Mackerras 提交于
      Commit b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8
      SPRs") added a definition of KVM_REG_PPC_WORT with the same register
      number as the existing KVM_REG_PPC_VRSAVE (though in fact the
      definitions are not identical because of the different register sizes.)
      
      For clarity, this moves KVM_REG_PPC_WORT to the next unused number,
      and also adds it to api.txt.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      e1d8a96d
    • A
      KVM: PPC: Add CAP to indicate hcall fixes · f2e91042
      Alexander Graf 提交于
      We worked around some nasty KVM magic page hcall breakages:
      
        1) NX bit not honored, so ignore NX when we detect it
        2) LE guests swizzle hypercall instruction
      
      Without these fixes in place, there's no way it would make sense to expose kvm
      hypercalls to a guest. Chances are immensely high it would trip over and break.
      
      So add a new CAP that gives user space a hint that we have workarounds for the
      bugs above in place. It can use those as hint to disable PV hypercalls when
      the guest CPU is anything POWER7 or higher and the host does not have fixes
      in place.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      f2e91042
    • A
      KVM: PPC: MPIC: Reset IRQ source private members · aae65596
      Alexander Graf 提交于
      When we reset the in-kernel MPIC controller, we forget to reset some hidden
      state such as destmask and output. This state is usually set when the guest
      writes to the IDR register for a specific IRQ line.
      
      To make sure we stay in sync and don't forget hidden state, treat reset of
      the IDR register as a simple write of the IDR register. That automatically
      updates all the hidden state as well.
      Reported-by: NPaul Janzen <pcj@pauljanzen.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      aae65596
    • A
      KVM: PPC: Graciously fail broken LE hypercalls · 42188365
      Alexander Graf 提交于
      There are LE Linux guests out there that don't handle hypercalls correctly.
      Instead of interpreting the instruction stream from device tree as big endian
      they assume it's a little endian instruction stream and fail.
      
      When we see an illegal instruction from such a byte reversed instruction stream,
      bail out graciously and just declare every hcall as error.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      42188365
    • A
      PPC: ePAPR: Fix hypercall on LE guest · 235959be
      Alexander Graf 提交于
      We get an array of instructions from the hypervisor via device tree that
      we write into a buffer that gets executed whenever we want to make an
      ePAPR compliant hypercall.
      
      However, the hypervisor passes us these instructions in BE order which
      we have to manually convert to LE when we want to run them in LE mode.
      
      With this fixup in place, I can successfully run LE kernels with KVM
      PV enabled on PR KVM.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      235959be
    • A
      KVM: PPC: BOOK3S: Remove open coded make_dsisr in alignment handler · ddca156a
      Aneesh Kumar K.V 提交于
      Use make_dsisr instead of open coding it. This also have
      the added benefit of handling alignment interrupt on additional
      instructions.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      ddca156a
    • A
      KVM: PPC: BOOK3S: Always use the saved DAR value · 7310f3a5
      Aneesh Kumar K.V 提交于
      Although it's optional, IBM POWER cpus always had DAR value set on
      alignment interrupt. So don't try to compute these values.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      7310f3a5
    • A
      PPC: KVM: Make NX bit available with magic page · 5c165aec
      Alexander Graf 提交于
      Because old kernels enable the magic page and then choke on NXed trampoline
      code we have to disable NX by default in KVM when we use the magic page.
      
      However, since commit b18db0b8 we have successfully fixed that and can now
      leave NX enabled, so tell the hypervisor about this.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      5c165aec