1. 28 Aug, 2020 2 commits
    • James Morse's avatar
      KVM: arm64: Survive synchronous exceptions caused by AT instructions · 88a84ccc
      James Morse authored
      KVM doesn't expect any synchronous exceptions when executing, any such
      exception leads to a panic(). AT instructions access the guest page
      tables, and can cause a synchronous external abort to be taken.
      The arm-arm is unclear on what should happen if the guest has configured
      the hardware update of the access-flag, and a memory type in TCR_EL1 that
      does not support atomic operations. B2.2.6 "Possible implementation
      restrictions on using atomic instructions" from DDI0487F.a lists
      synchronous external abort as a possible behaviour of atomic instructions
      that target memory that isn't writeback cacheable, but the page table
      walker may behave differently.
      Make KVM robust to synchronous exceptions caused by AT instructions.
      Add a get_user() style helper for AT instructions that returns -EFAULT
      if an exception was generated.
      While KVM's version of the exception table mixes synchronous and
      asynchronous exceptions, only one of these can occur at each location.
      Re-enter the guest when the AT instructions take an exception on the
      assumption the guest will take the same exception. This isn't guaranteed
      to make forward progress, as the AT instructions may always walk the page
      tables, but guest execution may use the translation cached in the TLB.
      This isn't a problem, as since commit 5dcd0fdb ("KVM: arm64: Defer guest
      entry when an asynchronous exception is pending"), KVM will return to the
      host to process IRQs allowing the rest of the system to keep running.
      Cc: stable@vger.kernel.org # <v5.3: 5dcd0fdb
       ("KVM: arm64: Defer guest entry when an asynchronous exception is pending")
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Reviewed-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • James Morse's avatar
      KVM: arm64: Add kvm_extable for vaxorcism code · e9ee186b
      James Morse authored
      KVM has a one instruction window where it will allow an SError exception
      to be consumed by the hypervisor without treating it as a hypervisor bug.
      This is used to consume asynchronous external abort that were caused by
      the guest.
      As we are about to add another location that survives unexpected exceptions,
      generalise this code to make it behave like the host's extable.
      KVM's version has to be mapped to EL2 to be accessible on nVHE systems.
      The SError vaxorcism code is a one instruction window, so has two entries
      in the extable. Because the KVM code is copied for VHE and nVHE, we end up
      with four entries, half of which correspond with code that isn't mapped.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Reviewed-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  2. 21 Aug, 2020 3 commits
    • Will Deacon's avatar
      KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set · b5331379
      Will Deacon authored
      When an MMU notifier call results in unmapping a range that spans multiple
      PGDs, we end up calling into cond_resched_lock() when crossing a PGD boundary,
      since this avoids running into RCU stalls during VM teardown. Unfortunately,
      if the VM is destroyed as a result of OOM, then blocking is not permitted
      and the call to the scheduler triggers the following BUG():
       | BUG: sleeping function called from invalid context at arch/arm64/kvm/mmu.c:394
       | in_atomic(): 1, irqs_disabled(): 0, non_block: 1, pid: 36, name: oom_reaper
       | INFO: lockdep is turned off.
       | CPU: 3 PID: 36 Comm: oom_reaper Not tainted 5.8.0 #1
       | Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
       | Call trace:
       |  dump_backtrace+0x0/0x284
       |  show_stack+0x1c/0x28
       |  dump_stack+0xf0/0x1a4
       |  ___might_sleep+0x2bc/0x2cc
       |  unmap_stage2_range+0x160/0x1ac
       |  kvm_unmap_hva_range+0x1a0/0x1c8
       |  kvm_mmu_notifier_invalidate_range_start+0x8c/0xf8
       |  __mmu_notifier_invalidate_range_start+0x218/0x31c
       |  mmu_notifier_invalidate_range_start_nonblock+0x78/0xb0
       |  __oom_reap_task_mm+0x128/0x268
       |  oom_reap_task+0xac/0x298
       |  oom_reaper+0x178/0x17c
       |  kthread+0x1e4/0x1fc
       |  ret_from_fork+0x10/0x30
      Use the new 'flags' argument to kvm_unmap_hva_range() to ensure that we
      only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is set in the notifier
      Cc: <stable@vger.kernel.org>
      Fixes: 8b3405e3
       ("kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd")
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Message-Id: <20200811102725.7121-3-will@kernel.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    • Will Deacon's avatar
      KVM: Pass MMU notifier range flags to kvm_unmap_hva_range() · fdfe7cbd
      Will Deacon authored
      The 'flags' field of 'struct mmu_notifier_range' is used to indicate
      whether invalidate_range_{start,end}() are permitted to block. In the
      case of kvm_mmu_notifier_invalidate_range_start(), this field is not
      forwarded on to the architecture-specific implementation of
      kvm_unmap_hva_range() and therefore the backend cannot sensibly decide
      whether or not to block.
      Add an extra 'flags' parameter to kvm_unmap_hva_range() so that
      architectures are aware as to whether or not they are permitted to block.
      Cc: <stable@vger.kernel.org>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      Message-Id: <20200811102725.7121-2-will@kernel.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    • Rob Herring's avatar
      KVM: arm64: Print warning when cpu erratum can cause guests to deadlock · abf532cc
      Rob Herring authored
      If guests don't have certain CPU erratum workarounds implemented, then
      there is a possibility a guest can deadlock the system. IOW, only trusted
      guests should be used on systems with the erratum.
      This is the case for Cortex-A57 erratum 832075.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: James Morse <james.morse@arm.com>
      Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: kvmarm@lists.cs.columbia.edu
      Link: https://lore.kernel.org/r/20200803193127.3012242-2-robh@kernel.org
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  3. 30 Jul, 2020 5 commits
  4. 28 Jul, 2020 3 commits
  5. 22 Jul, 2020 1 commit
  6. 21 Jul, 2020 1 commit
    • Will Deacon's avatar
      arm64: Reduce the number of header files pulled into vmlinux.lds.S · 5f1f7f6c
      Will Deacon authored
      Although vmlinux.lds.S smells like an assembly file and is compiled
      with __ASSEMBLY__ defined, it's actually just fed to the preprocessor to
      create our linker script. This means that any assembly macros defined
      by headers that it includes will result in a helpful link error:
      | aarch64-linux-gnu-ld:./arch/arm64/kernel/vmlinux.lds:1: syntax error
      In preparation for an arm64-private asm/rwonce.h implementation, which
      will end up pulling assembly macros into linux/compiler.h, reduce the
      number of headers we include directly and transitively in vmlinux.lds.S
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
  7. 10 Jul, 2020 1 commit
  8. 09 Jul, 2020 3 commits
  9. 07 Jul, 2020 13 commits
  10. 06 Jul, 2020 2 commits
    • Andrew Scull's avatar
      KVM: arm64: Stop clobbering x0 for HVC_SOFT_RESTART · b9e10d4a
      Andrew Scull authored
      HVC_SOFT_RESTART is given values for x0-2 that it should installed
      before exiting to the new address so should not set x0 to stub HVC
      success or failure code.
      Fixes: af42f204
       ("arm64: hyp-stub: Zero x0 on successful stub handling")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndrew Scull <ascull@google.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20200706095259.1338221-1-ascull@google.com
    • Marc Zyngier's avatar
      KVM: arm64: PMU: Fix per-CPU access in preemptible context · 146f76cc
      Marc Zyngier authored
      Commit 07da1ffa ("KVM: arm64: Remove host_cpu_context
      member from vcpu structure") has, by removing the host CPU
      context pointer, exposed that kvm_vcpu_pmu_restore_guest
      is called in preemptible contexts:
      [  266.932442] BUG: using smp_processor_id() in preemptible [00000000] code: qemu-system-aar/779
      [  266.939721] caller is debug_smp_processor_id+0x20/0x30
      [  266.944157] CPU: 2 PID: 779 Comm: qemu-system-aar Tainted: G            E     5.8.0-rc3-00015-g8d4aa58b2fe3 #1374
      [  266.954268] Hardware name: amlogic w400/w400, BIOS 2020.04 05/22/2020
      [  266.960640] Call trace:
      [  266.963064]  dump_backtrace+0x0/0x1e0
      [  266.966679]  show_stack+0x20/0x30
      [  266.969959]  dump_stack+0xe4/0x154
      [  266.973338]  check_preemption_disabled+0xf8/0x108
      [  266.977978]  debug_smp_processor_id+0x20/0x30
      [  266.982307]  kvm_vcpu_pmu_restore_guest+0x2c/0x68
      [  266.986949]  access_pmcr+0xf8/0x128
      [  266.990399]  perform_access+0x8c/0x250
      [  266.994108]  kvm_handle_sys_reg+0x10c/0x2f8
      [  266.998247]  handle_exit+0x78/0x200
      [  267.001697]  kvm_arch_vcpu_ioctl_run+0x2ac/0xab8
      Note that the bug was always there, it is only the switch to
      using percpu accessors that made it obvious.
      The fix is to wrap these accesses in a preempt-disabled section,
      so that we sample a coherent context on trap from the guest.
      Fixes: 435e53fb
       ("arm64: KVM: Enable VHE support for :G/:H perf event modifiers")
      Cc:: Andrew Murray <amurray@thegoodpenguin.co.uk>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
  11. 05 Jul, 2020 6 commits