1. 28 3月, 2018 1 次提交
  2. 20 3月, 2018 1 次提交
  3. 19 3月, 2018 1 次提交
    • C
      KVM: arm64: Avoid storing the vcpu pointer on the stack · 4464e210
      Christoffer Dall 提交于
      We already have the percpu area for the host cpu state, which points to
      the VCPU, so there's no need to store the VCPU pointer on the stack on
      every context switch.  We can be a little more clever and just use
      tpidr_el2 for the percpu offset and load the VCPU pointer from the host
      context.
      
      This has the benefit of being able to retrieve the host context even
      when our stack is corrupted, and it has a potential performance benefit
      because we trade a store plus a load for an mrs and a load on a round
      trip to the guest.
      
      This does require us to calculate the percpu offset without including
      the offset from the kernel mapping of the percpu array to the linear
      mapping of the array (which is what we store in tpidr_el1), because a
      PC-relative generated address in EL2 is already giving us the hyp alias
      of the linear mapping of a kernel address.  We do this in
      __cpu_init_hyp_mode() by using kvm_ksym_ref().
      
      The code that accesses ESR_EL2 was previously using an alternative to
      use the _EL1 accessor on VHE systems, but this was actually unnecessary
      as the _EL1 accessor aliases the ESR_EL2 register on VHE, and the _EL2
      accessor does the same thing on both systems.
      
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NAndrew Jones <drjones@redhat.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      4464e210
  4. 16 1月, 2018 1 次提交
    • J
      KVM: arm64: Handle RAS SErrors from EL2 on guest exit · 0067df41
      James Morse 提交于
      We expect to have firmware-first handling of RAS SErrors, with errors
      notified via an APEI method. For systems without firmware-first, add
      some minimal handling to KVM.
      
      There are two ways KVM can take an SError due to a guest, either may be a
      RAS error: we exit the guest due to an SError routed to EL2 by HCR_EL2.AMO,
      or we take an SError from EL2 when we unmask PSTATE.A from __guest_exit.
      
      The current SError from EL2 code unmasks SError and tries to fence any
      pending SError into a single instruction window. It then leaves SError
      unmasked.
      
      With the v8.2 RAS Extensions we may take an SError for a 'corrected'
      error, but KVM is only able to handle SError from EL2 if they occur
      during this single instruction window...
      
      The RAS Extensions give us a new instruction to synchronise and
      consume SErrors. The RAS Extensions document (ARM DDI0587),
      '2.4.1 ESB and Unrecoverable errors' describes ESB as synchronising
      SError interrupts generated by 'instructions, translation table walks,
      hardware updates to the translation tables, and instruction fetches on
      the same PE'. This makes ESB equivalent to KVMs existing
      'dsb, mrs-daifclr, isb' sequence.
      
      Use the alternatives to synchronise and consume any SError using ESB
      instead of unmasking and taking the SError. Set ARM_EXIT_WITH_SERROR_BIT
      in the exit_code so that we can restart the vcpu if it turns out this
      SError has no impact on the vcpu.
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      0067df41
  5. 13 1月, 2018 1 次提交
  6. 09 1月, 2018 1 次提交
  7. 08 9月, 2016 3 次提交
  8. 04 7月, 2016 1 次提交
  9. 03 5月, 2016 1 次提交
    • J
      arm64: kvm: Fix kvm teardown for systems using the extended idmap · c612505f
      James Morse 提交于
      If memory is located above 1<<VA_BITS, kvm adds an extra level to its page
      tables, merging the runtime tables and boot tables that contain the idmap.
      This lets us avoid the trampoline dance during initialisation.
      
      This also means there is no trampoline page mapped, so
      __cpu_reset_hyp_mode() can't call __kvm_hyp_reset() in this page. The good
      news is the idmap is still mapped, so we don't need the trampoline page.
      The bad news is we can't call it directly as the idmap is above
      HYP_PAGE_OFFSET, so its address is masked by kvm_call_hyp.
      
      Add a function __extended_idmap_trampoline which will branch into
      __kvm_hyp_reset in the idmap, change kvm_hyp_reset_entry() to return
      this address if __kvm_cpu_uses_extended_idmap(). In this case
      __kvm_hyp_reset() will still switch to the boot tables (which are the
      merged tables that were already in use), and branch into the idmap (where
      it already was).
      
      This fixes boot failures on these systems, where we fail to execute the
      missing trampoline page when tearing down kvm in init_subsystems():
      [    2.508922] kvm [1]: 8-bit VMID
      [    2.512057] kvm [1]: Hyp mode initialized successfully
      [    2.517242] kvm [1]: interrupt-controller@e1140000 IRQ13
      [    2.522622] kvm [1]: timer IRQ3
      [    2.525783] Kernel panic - not syncing: HYP panic:
      [    2.525783] PS:200003c9 PC:0000007ffffff820 ESR:86000005
      [    2.525783] FAR:0000007ffffff820 HPFAR:00000000003ffff0 PAR:0000000000000000
      [    2.525783] VCPU:          (null)
      [    2.525783]
      [    2.547667] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W       4.6.0-rc5+ #1
      [    2.555137] Hardware name: Default string Default string/Default string, BIOS ROD0084E 09/03/2015
      [    2.563994] Call trace:
      [    2.566432] [<ffffff80080888d0>] dump_backtrace+0x0/0x240
      [    2.571818] [<ffffff8008088b24>] show_stack+0x14/0x20
      [    2.576858] [<ffffff80083423ac>] dump_stack+0x94/0xb8
      [    2.581899] [<ffffff8008152130>] panic+0x10c/0x250
      [    2.586677] [<ffffff8008152024>] panic+0x0/0x250
      [    2.591281] SMP: stopping secondary CPUs
      [    3.649692] SMP: failed to stop secondary CPUs 0-2,4-7
      [    3.654818] Kernel Offset: disabled
      [    3.658293] Memory Limit: none
      [    3.661337] ---[ end Kernel panic - not syncing: HYP panic:
      [    3.661337] PS:200003c9 PC:0000007ffffff820 ESR:86000005
      [    3.661337] FAR:0000007ffffff820 HPFAR:00000000003ffff0 PAR:0000000000000000
      [    3.661337] VCPU:          (null)
      [    3.661337]
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      c612505f
  10. 01 3月, 2016 1 次提交
  11. 14 12月, 2015 4 次提交