1. 10 10月, 2014 1 次提交
  2. 29 9月, 2014 1 次提交
    • V
      arm: kvm: fix CPU hotplug · 37a34ac1
      Vladimir Murzin 提交于
      On some platforms with no power management capabilities, the hotplug
      implementation is allowed to return from a smp_ops.cpu_die() call as a
      function return. Upon a CPU onlining event, the KVM CPU notifier tries
      to reinstall the hyp stub, which fails on platform where no reset took
      place following a hotplug event, with the message:
      
      CPU1: smp_ops.cpu_die() returned, trying to resuscitate
      CPU1: Booted secondary processor
      Kernel panic - not syncing: unexpected prefetch abort in Hyp mode at: 0x80409540
      unexpected data abort in Hyp mode at: 0x80401fe8
      unexpected HVC/SVC trap in Hyp mode at: 0x805c6170
      
      since KVM code is trying to reinstall the stub on a system where it is
      already configured.
      
      To prevent this issue, this patch adds a check in the KVM hotplug
      notifier that detects if the HYP stub really needs re-installing when a
      CPU is onlined and skips the installation call if the stub is already in
      place, which means that the CPU has not been reset.
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      37a34ac1
  3. 26 9月, 2014 2 次提交
  4. 19 9月, 2014 2 次提交
  5. 11 9月, 2014 1 次提交
  6. 29 8月, 2014 2 次提交
  7. 28 8月, 2014 4 次提交
  8. 22 8月, 2014 1 次提交
  9. 28 7月, 2014 1 次提交
  10. 18 7月, 2014 2 次提交
    • R
      ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ · 6ebbf2ce
      Russell King 提交于
      ARMv6 and greater introduced a new instruction ("bx") which can be used
      to return from function calls.  Recent CPUs perform better when the
      "bx lr" instruction is used rather than the "mov pc, lr" instruction,
      and this sequence is strongly recommended to be used by the ARM
      architecture manual (section A.4.1.1).
      
      We provide a new macro "ret" with all its variants for the condition
      code which will resolve to the appropriate instruction.
      
      Rather than doing this piecemeal, and miss some instances, change all
      the "mov pc" instances to use the new macro, with the exception of
      the "movs" instruction and the kprobes code.  This allows us to detect
      the "mov pc, lr" case and fix it up - and also gives us the possibility
      of deploying this for other registers depending on the CPU selection.
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1
      Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S
      Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood
      Tested-by: NShawn Guo <shawn.guo@freescale.com>
      Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs
      Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385
      Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci
      Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp
      Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen
      Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M
      Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6ebbf2ce
    • R
      ARM: make it easier to check the CPU part number correctly · af040ffc
      Russell King 提交于
      Ensure that platform maintainers check the CPU part number in the right
      manner: the CPU part number is meaningless without also checking the
      CPU implement(e|o)r (choose your preferred spelling!)  Provide an
      interface which returns both the implementer and part number together,
      and update the definitions to include the implementer.
      
      Mark the old function as being deprecated... indeed, using the old
      function with the definitions will now always evaluate as false, so
      people must update their un-merged code to the new function.  While
      this could be avoided by adding new definitions, we'd also have to
      create new names for them which would be awkward.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      af040ffc
  11. 11 7月, 2014 11 次提交
  12. 30 4月, 2014 8 次提交
  13. 28 4月, 2014 1 次提交
    • M
      arm: KVM: fix possible misalignment of PGDs and bounce page · 5d4e08c4
      Mark Salter 提交于
      The kvm/mmu code shared by arm and arm64 uses kalloc() to allocate
      a bounce page (if hypervisor init code crosses page boundary) and
      hypervisor PGDs. The problem is that kalloc() does not guarantee
      the proper alignment. In the case of the bounce page, the page sized
      buffer allocated may also cross a page boundary negating the purpose
      and leading to a hang during kvm initialization. Likewise the PGDs
      allocated may not meet the minimum alignment requirements of the
      underlying MMU. This patch uses __get_free_page() to guarantee the
      worst case alignment needs of the bounce page and PGDs on both arm
      and arm64.
      
      Cc: <stable@vger.kernel.org> # 3.10+
      Signed-off-by: NMark Salter <msalter@redhat.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      5d4e08c4
  14. 26 4月, 2014 1 次提交
  15. 20 3月, 2014 1 次提交
    • S
      arm, kvm: Fix CPU hotplug callback registration · 8146875d
      Srivatsa S. Bhat 提交于
      On 03/15/2014 12:40 AM, Christoffer Dall wrote:
      > On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
      >> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
      >>> On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
      >>>> Subsystems that want to register CPU hotplug callbacks, as well as perform
      >>>> initialization for the CPUs that are already online, often do it as shown
      >>>> below:
      >>>>
      [...]
      >>> Just so we're clear, the existing code was simply racy as not prone to
      >>> deadlocks, right?
      
      > >>> This makes it clear that the test above for compatible CPUs can be quite
      > >>> easily evaded by using CPU hotplug, but we don't really have a good
      > >>> solution for handling that yet...  Hmmm, grumble grumble, I guess if you
      > >>> hotplug unsupported CPUs on a KVM/ARM system for now, stuff will break.
      
      >>
      >> In this particular case, there was no deadlock possibility, rather the
      >> existing code had insufficient synchronization against CPU hotplug.
      >>
      >> init_hyp_mode() would invoke cpu_init_hyp_mode() on currently online CPUs
      >> using on_each_cpu(). If a CPU came online after this point and before calling
      >> register_cpu_notifier(), that CPU would remain uninitialized because this
      >> subsystem would miss the hot-online event. This patch fixes this bug and
      >> also uses the new synchronization method (instead of get/put_online_cpus())
      >> to ensure that we don't deadlock with CPU hotplug.
      >>
      >
      > Yes, that was my conclusion as well.  Thanks for clarifying.  (It could
      > be noted in the commit message as well if you should feel so inclined).
      >
      
      Please find the patch with updated changelog (and your Ack) below.
      (No changes in code).
      
      From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Subject: [PATCH] arm, kvm: Fix CPU hotplug callback registration
      
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      In the existing arm kvm code, there is no synchronization with CPU hotplug
      to avoid missing the hotplug events that might occur after invoking
      init_hyp_mode() and before calling register_cpu_notifier(). Fix this bug
      and also use the new synchronization method (instead of get/put_online_cpus())
      to ensure that we don't deadlock with CPU hotplug.
      
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ingo Molnar <mingo@kernel.org>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      Acked-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8146875d
  16. 03 3月, 2014 1 次提交
    • M
      ARM: KVM: fix warning in mmu.c · 56041bf9
      Marc Zyngier 提交于
      Compiling with THP enabled leads to the following warning:
      
      arch/arm/kvm/mmu.c: In function ‘unmap_range’:
      arch/arm/kvm/mmu.c:177:39: warning: ‘pte’ may be used uninitialized in this function [-Wmaybe-uninitialized]
         if (kvm_pmd_huge(*pmd) || page_empty(pte)) {
                                              ^
      Code inspection reveals that these two cases are mutually exclusive,
      so GCC is a bit overzealous here. Silence it anyway by initializing
      pte to NULL and testing it later on.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NChristoffer Dall <christoffer.dall@linaro.org>
      56041bf9