1. 30 6月, 2021 1 次提交
  2. 15 5月, 2021 1 次提交
  3. 17 4月, 2021 2 次提交
  4. 07 4月, 2021 3 次提交
  5. 19 3月, 2021 4 次提交
  6. 12 3月, 2021 1 次提交
  7. 26 1月, 2021 1 次提交
  8. 02 12月, 2020 1 次提交
    • Y
      KVM: arm64: Add usage of stage 2 fault lookup level in user_mem_abort() · 7d894834
      Yanan Wang 提交于
      If we get a FSC_PERM fault, just using (logging_active && writable) to
      determine calling kvm_pgtable_stage2_map(). There will be two more cases
      we should consider.
      
      (1) After logging_active is configged back to false from true. When we
      get a FSC_PERM fault with write_fault and adjustment of hugepage is needed,
      we should merge tables back to a block entry. This case is ignored by still
      calling kvm_pgtable_stage2_relax_perms(), which will lead to an endless
      loop and guest panic due to soft lockup.
      
      (2) We use (FSC_PERM && logging_active && writable) to determine
      collapsing a block entry into a table by calling kvm_pgtable_stage2_map().
      But sometimes we may only need to relax permissions when trying to write
      to a page other than a block.
      In this condition,using kvm_pgtable_stage2_relax_perms() will be fine.
      
      The ISS filed bit[1:0] in ESR_EL2 regesiter indicates the stage2 lookup
      level at which a D-abort or I-abort occurred. By comparing granule of
      the fault lookup level with vma_pagesize, we can strictly distinguish
      conditions of calling kvm_pgtable_stage2_relax_perms() or
      kvm_pgtable_stage2_map(), and the above two cases will be well considered.
      Suggested-by: NKeqian Zhu <zhukeqian1@huawei.com>
      Signed-off-by: NYanan Wang <wangyanan55@huawei.com>
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Acked-by: NWill Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20201201201034.116760-4-wangyanan55@huawei.com
      7d894834
  9. 10 11月, 2020 2 次提交
  10. 07 11月, 2020 1 次提交
  11. 30 10月, 2020 2 次提交
  12. 02 10月, 2020 1 次提交
  13. 19 9月, 2020 1 次提交
    • M
      KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch · c4ad98e4
      Marc Zyngier 提交于
      KVM currently assumes that an instruction abort can never be a write.
      This is in general true, except when the abort is triggered by
      a S1PTW on instruction fetch that tries to update the S1 page tables
      (to set AF, for example).
      
      This can happen if the page tables have been paged out and brought
      back in without seeing a direct write to them (they are thus marked
      read only), and the fault handling code will make the PT executable(!)
      instead of writable. The guest gets stuck forever.
      
      In these conditions, the permission fault must be considered as
      a write so that the Stage-1 update can take place. This is essentially
      the I-side equivalent of the problem fixed by 60e21a0e ("arm64: KVM:
      Take S1 walks into account when determining S2 write faults").
      
      Update kvm_is_write_fault() to return true on IABT+S1PTW, and introduce
      kvm_vcpu_trap_is_exec_fault() that only return true when no faulting
      on a S1 fault. Additionally, kvm_vcpu_dabt_iss1tw() is renamed to
      kvm_vcpu_abt_iss1tw(), as the above makes it plain that it isn't
      specific to data abort.
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Reviewed-by: NWill Deacon <will@kernel.org>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20200915104218.1284701-2-maz@kernel.org
      c4ad98e4
  14. 18 9月, 2020 3 次提交
  15. 11 9月, 2020 13 次提交
  16. 04 9月, 2020 2 次提交
  17. 22 8月, 2020 1 次提交
    • W
      KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set · b5331379
      Will Deacon 提交于
      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
      flags.
      
      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: NWill Deacon <will@kernel.org>
      Message-Id: <20200811102725.7121-3-will@kernel.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b5331379