1. 09 12月, 2016 1 次提交
    • M
      arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest · 21cbe3cc
      Marc Zyngier 提交于
      The ARMv8 architecture allows the cycle counter to be configured
      by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
      hence accessing PMCCFILTR_EL0. But it disallows the use of
      PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
      PMXEVCNTR_EL0.
      
      Linux itself doesn't violate this rule, but we may end up with
      PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
      guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
      despite the guest not having done anything wrong.
      
      In order to avoid this unfortunate course of events (haha!), let's
      sanitize PMSELR_EL0 on guest entry. This ensures that the guest
      won't explode unexpectedly.
      
      Cc: stable@vger.kernel.org #4.6+
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      21cbe3cc
  2. 03 12月, 2016 2 次提交
  3. 02 12月, 2016 3 次提交
  4. 01 12月, 2016 1 次提交
  5. 29 11月, 2016 5 次提交
  6. 21 11月, 2016 1 次提交
  7. 18 11月, 2016 3 次提交
  8. 17 11月, 2016 1 次提交
  9. 16 11月, 2016 2 次提交
    • C
      locking/core, arch: Remove cpu_relax_lowlatency() · 5bd0b85b
      Christian Borntraeger 提交于
      As there are no users left, we can remove cpu_relax_lowlatency()
      implementations from every architecture.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Cc: <linux-arch@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1477386195-32736-6-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5bd0b85b
    • C
      locking/core: Introduce cpu_relax_yield() · 79ab11cd
      Christian Borntraeger 提交于
      For spinning loops people do often use barrier() or cpu_relax().
      For most architectures cpu_relax and barrier are the same, but on
      some architectures cpu_relax can add some latency.
      For example on power,sparc64 and arc, cpu_relax can shift the CPU
      towards other hardware threads in an SMT environment.
      On s390 cpu_relax does even more, it uses an hypercall to the
      hypervisor to give up the timeslice.
      In contrast to the SMT yielding this can result in larger latencies.
      In some places this latency is unwanted, so another variant
      "cpu_relax_lowlatency" was introduced. Before this is used in more
      and more places, lets revert the logic and provide a cpu_relax_yield
      that can be called in places where yielding is more important than
      latency. By default this is the same as cpu_relax on all architectures.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Noam Camus <noamc@ezchip.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: virtualization@lists.linux-foundation.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1477386195-32736-2-git-send-email-borntraeger@de.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      79ab11cd
  10. 14 11月, 2016 1 次提交
  11. 13 11月, 2016 1 次提交
    • L
      efi: Allow bitness-agnostic protocol calls · 3552fdf2
      Lukas Wunner 提交于
      We already have a macro to invoke boot services which on x86 adapts
      automatically to the bitness of the EFI firmware:  efi_call_early().
      
      The macro allows sharing of functions across arches and bitness variants
      as long as those functions only call boot services.  However in practice
      functions in the EFI stub contain a mix of boot services calls and
      protocol calls.
      
      Add an efi_call_proto() macro for bitness-agnostic protocol calls to
      allow sharing more code across arches as well as deduplicating 32 bit
      and 64 bit code paths.
      
      On x86, implement it using a new efi_table_attr() macro for bitness-
      agnostic table lookups.  Refactor efi_call_early() to make use of the
      same macro.  (The resulting object code remains identical.)
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andreas Noever <andreas.noever@gmail.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20161112213237.8804-8-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3552fdf2
  12. 11 11月, 2016 1 次提交
  13. 09 11月, 2016 3 次提交
  14. 08 11月, 2016 1 次提交
  15. 06 11月, 2016 1 次提交
  16. 05 11月, 2016 1 次提交
    • M
      arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU · 94d0e598
      Marc Zyngier 提交于
      Architecturally, TLBs are private to the (physical) CPU they're
      associated with. But when multiple vcpus from the same VM are
      being multiplexed on the same CPU, the TLBs are not private
      to the vcpus (and are actually shared across the VMID).
      
      Let's consider the following scenario:
      
      - vcpu-0 maps PA to VA
      - vcpu-1 maps PA' to VA
      
      If run on the same physical CPU, vcpu-1 can hit TLB entries generated
      by vcpu-0 accesses, and access the wrong physical page.
      
      The solution to this is to keep a per-VM map of which vcpu ran last
      on each given physical CPU, and invalidate local TLBs when switching
      to a different vcpu from the same VM.
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      94d0e598
  17. 03 11月, 2016 2 次提交
  18. 01 11月, 2016 1 次提交
  19. 27 10月, 2016 4 次提交
    • C
      arm64: dts: mediatek: add USB3 DRD driver · c0891284
      Chunfeng Yun 提交于
      USB3 DRD driver is added for MT8173-EVB, and xHCI driver
      becomes its subnode
      Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0891284
    • N
      arm64: mm: fix __page_to_voff definition · 3fa72fe9
      Neeraj Upadhyay 提交于
      Fix parameter name for __page_to_voff, to match its definition.
      At present, we don't see any issue, as page_to_virt's caller
      declares 'page'.
      
      Fixes: 9f287591 ("arm64: mm: restrict virt_to_page() to the linear mapping")
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NNeeraj Upadhyay <neeraju@codeaurora.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      3fa72fe9
    • H
      arm64/numa: fix incorrect log for memory-less node · 3f7a09f4
      Hanjun Guo 提交于
      When booting on NUMA system with memory-less node (no
      memory dimm on this memory controller), the print
      for setup_node_data() is incorrect:
      
      NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
      
      It can be fixed by printing [mem 0x00000000-0x00000000] when
      end_pfn is 0, but print <memory-less node> will be more useful.
      
      Fixes: 1a2db300 ("arm64, numa: Add NUMA support for arm64 platforms.")
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yisheng Xie <xieyisheng1@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      3f7a09f4
    • Y
      arm64/numa: fix pcpu_cpu_distance() to get correct CPU proximity · 26984c3b
      Yisheng Xie 提交于
      The pcpu_build_alloc_info() function group CPUs according to their
      proximity, by call callback function @cpu_distance_fn from different
      ARCHs.
      
      For arm64 the callback of @cpu_distance_fn is
          pcpu_cpu_distance(from, to)
              -> node_distance(from, to)
      The @from and @to for function node_distance() should be nid.
      
      However, pcpu_cpu_distance() in arch/arm64/mm/numa.c just past the
      cpu id for @from and @to, and didn't convert to numa node id.
      
      For this incorrect cpu proximity get from ARCH, it may cause each CPU
      in one group and make group_cnt out of bound:
      
      	setup_per_cpu_areas()
      		pcpu_embed_first_chunk()
      			pcpu_build_alloc_info()
      in pcpu_build_alloc_info, since cpu_distance_fn will return
      REMOTE_DISTANCE if we pass cpu ids (0,1,2...), so
      cpu_distance_fn(cpu, tcpu) > LOCAL_DISTANCE will wrongly be ture.
      
      This may results in triggering the BUG_ON(unit != nr_units) later:
      
      [    0.000000] kernel BUG at mm/percpu.c:1916!
      [    0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc1-00003-g14155caf-dirty #26
      [    0.000000] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
      [    0.000000] task: ffff000008d6e900 task.stack: ffff000008d60000
      [    0.000000] PC is at pcpu_embed_first_chunk+0x420/0x704
      [    0.000000] LR is at pcpu_embed_first_chunk+0x3bc/0x704
      [    0.000000] pc : [<ffff000008c754f4>] lr : [<ffff000008c75490>] pstate: 800000c5
      [    0.000000] sp : ffff000008d63eb0
      [    0.000000] x29: ffff000008d63eb0 [    0.000000] x28: 0000000000000000
      [    0.000000] x27: 0000000000000040 [    0.000000] x26: ffff8413fbfcef00
      [    0.000000] x25: 0000000000000042 [    0.000000] x24: 0000000000000042
      [    0.000000] x23: 0000000000001000 [    0.000000] x22: 0000000000000046
      [    0.000000] x21: 0000000000000001 [    0.000000] x20: ffff000008cb3bc8
      [    0.000000] x19: ffff8413fbfcf570 [    0.000000] x18: 0000000000000000
      [    0.000000] x17: ffff000008e49ae0 [    0.000000] x16: 0000000000000003
      [    0.000000] x15: 000000000000001e [    0.000000] x14: 0000000000000004
      [    0.000000] x13: 0000000000000000 [    0.000000] x12: 000000000000006f
      [    0.000000] x11: 00000413fbffff00 [    0.000000] x10: 0000000000000004
      [    0.000000] x9 : 0000000000000000 [    0.000000] x8 : 0000000000000001
      [    0.000000] x7 : ffff8413fbfcf63c [    0.000000] x6 : ffff000008d65d28
      [    0.000000] x5 : ffff000008d65e50 [    0.000000] x4 : 0000000000000000
      [    0.000000] x3 : ffff000008cb3cc8 [    0.000000] x2 : 0000000000000040
      [    0.000000] x1 : 0000000000000040 [    0.000000] x0 : 0000000000000000
      [...]
      [    0.000000] Call trace:
      [    0.000000] Exception stack(0xffff000008d63ce0 to 0xffff000008d63e10)
      [    0.000000] 3ce0: ffff8413fbfcf570 0001000000000000 ffff000008d63eb0 ffff000008c754f4
      [    0.000000] 3d00: ffff000008d63d50 ffff0000081af210 00000413fbfff010 0000000000001000
      [    0.000000] 3d20: ffff000008d63d50 ffff0000081af220 00000413fbfff010 0000000000001000
      [    0.000000] 3d40: 00000413fbfcef00 0000000000000004 ffff000008d63db0 ffff0000081af390
      [    0.000000] 3d60: 00000413fbfcef00 0000000000001000 0000000000000000 0000000000001000
      [    0.000000] 3d80: 0000000000000000 0000000000000040 0000000000000040 ffff000008cb3cc8
      [    0.000000] 3da0: 0000000000000000 ffff000008d65e50 ffff000008d65d28 ffff8413fbfcf63c
      [    0.000000] 3dc0: 0000000000000001 0000000000000000 0000000000000004 00000413fbffff00
      [    0.000000] 3de0: 000000000000006f 0000000000000000 0000000000000004 000000000000001e
      [    0.000000] 3e00: 0000000000000003 ffff000008e49ae0
      [    0.000000] [<ffff000008c754f4>] pcpu_embed_first_chunk+0x420/0x704
      [    0.000000] [<ffff000008c6658c>] setup_per_cpu_areas+0x38/0xc8
      [    0.000000] [<ffff000008c608d8>] start_kernel+0x10c/0x390
      [    0.000000] [<ffff000008c601d8>] __primary_switched+0x5c/0x64
      [    0.000000] Code: b8018660 17ffffd7 6b16037f 54000080 (d4210000)
      [    0.000000] ---[ end trace 0000000000000000 ]---
      [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
      
      Fix by getting cpu's node id with early_cpu_to_node() then pass it
      to node_distance() as the original intention.
      
      Fixes: 7af3a0a9 ("arm64/numa: support HAVE_SETUP_PER_CPU_AREA")
      Signed-off-by: NYisheng Xie <xieyisheng1@huawei.com>
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Zhen Lei <thunder.leizhen@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      26984c3b
  20. 25 10月, 2016 1 次提交
  21. 24 10月, 2016 1 次提交
  22. 22 10月, 2016 3 次提交
    • M
      arm64: dts: uniphier: change MIO node to SD control node · 8e68c65d
      Masahiro Yamada 提交于
      I made a mistake bacuse the Media I/O block is not implemented in
      this SoC.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      8e68c65d
    • M
      arm64: uniphier: select ARCH_HAS_RESET_CONTROLLER · 75924903
      Masahiro Yamada 提交于
      The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
      merged.  Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      75924903
    • W
      arm64: KVM: Take S1 walks into account when determining S2 write faults · 60e21a0e
      Will Deacon 提交于
      The WnR bit in the HSR/ESR_EL2 indicates whether a data abort was
      generated by a read or a write instruction. For stage 2 data aborts
      generated by a stage 1 translation table walk (i.e. the actual page
      table access faults at EL2), the WnR bit therefore reports whether the
      instruction generating the walk was a load or a store, *not* whether the
      page table walker was reading or writing the entry.
      
      For page tables marked as read-only at stage 2 (e.g. due to KSM merging
      them with the tables from another guest), this could result in livelock,
      where a page table walk generated by a load instruction attempts to
      set the access flag in the stage 1 descriptor, but fails to trigger
      CoW in the host since only a read fault is reported.
      
      This patch modifies the arm64 kvm_vcpu_dabt_iswrite function to
      take into account stage 2 faults in stage 1 walks. Since DBM cannot be
      disabled at EL2 for CPUs that implement it, we assume that these faults
      are always causes by writes, avoiding the livelock situation at the
      expense of occasional, spurious CoWs.
      
      We could, in theory, do a bit better by checking the guest TCR
      configuration and inspecting the page table to see why the PTE faulted.
      However, I doubt this is measurable in practice, and the threat of
      livelock is real.
      
      Cc: <stable@vger.kernel.org>
      Cc: Julien Grall <julien.grall@arm.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      60e21a0e