1. 12 4月, 2018 1 次提交
  2. 28 3月, 2018 1 次提交
  3. 20 3月, 2018 1 次提交
  4. 19 3月, 2018 22 次提交
  5. 26 2月, 2018 1 次提交
  6. 12 2月, 2018 1 次提交
  7. 07 2月, 2018 2 次提交
  8. 16 1月, 2018 2 次提交
    • J
      KVM: arm64: Save ESR_EL2 on guest SError · c60590b5
      James Morse 提交于
      When we exit a guest due to an SError the vcpu fault info isn't updated
      with the ESR. Today this is only done for traps.
      
      The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's
      fault_info with the ESR on SError so that handle_exit() can determine
      if this was a RAS SError and decode its severity.
      Acked-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>
      c60590b5
    • J
      KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2. · 4715c14b
      James Morse 提交于
      Prior to v8.2's RAS Extensions, the HCR_EL2.VSE 'virtual SError' feature
      generated an SError with an implementation defined ESR_EL1.ISS, because we
      had no mechanism to specify the ESR value.
      
      On Juno this generates an all-zero ESR, the most significant bit 'ISV'
      is clear indicating the remainder of the ISS field is invalid.
      
      With the RAS Extensions we have a mechanism to specify this value, and the
      most significant bit has a new meaning: 'IDS - Implementation Defined
      Syndrome'. An all-zero SError ESR now means: 'RAS error: Uncategorized'
      instead of 'no valid ISS'.
      
      Add KVM support for the VSESR_EL2 register to specify an ESR value when
      HCR_EL2.VSE generates a virtual SError. Change kvm_inject_vabt() to
      specify an implementation-defined value.
      
      We only need to restore the VSESR_EL2 value when HCR_EL2.VSE is set, KVM
      save/restores this bit during __{,de}activate_traps() and hardware clears the
      bit once the guest has consumed the virtual-SError.
      
      Future patches may add an API (or KVM CAP) to pend a virtual SError with
      a specified ESR.
      
      Cc: Dongjiu Geng <gengdongjiu@huawei.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      4715c14b
  9. 13 1月, 2018 1 次提交
    • J
      KVM: arm64: Change hyp_panic()s dependency on tpidr_el2 · c97e166e
      James Morse 提交于
      Make tpidr_el2 a cpu-offset for per-cpu variables in the same way the
      host uses tpidr_el1. This lets tpidr_el{1,2} have the same value, and
      on VHE they can be the same register.
      
      KVM calls hyp_panic() when anything unexpected happens. This may occur
      while a guest owns the EL1 registers. KVM stashes the vcpu pointer in
      tpidr_el2, which it uses to find the host context in order to restore
      the host EL1 registers before parachuting into the host's panic().
      
      The host context is a struct kvm_cpu_context allocated in the per-cpu
      area, and mapped to hyp. Given the per-cpu offset for this CPU, this is
      easy to find. Change hyp_panic() to take a pointer to the
      struct kvm_cpu_context. Wrap these calls with an asm function that
      retrieves the struct kvm_cpu_context from the host's per-cpu area.
      
      Copy the per-cpu offset from the hosts tpidr_el1 into tpidr_el2 during
      kvm init. (Later patches will make this unnecessary for VHE hosts)
      
      We print out the vcpu pointer as part of the panic message. Add a back
      reference to the 'running vcpu' in the host cpu context to preserve this.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Reviewed-by: NChristoffer Dall <cdall@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      c97e166e
  10. 09 1月, 2018 3 次提交
  11. 08 1月, 2018 1 次提交
  12. 30 11月, 2017 1 次提交
  13. 06 11月, 2017 1 次提交
    • C
      KVM: arm/arm64: Move timer save/restore out of the hyp code · 688c50aa
      Christoffer Dall 提交于
      As we are about to be lazy with saving and restoring the timer
      registers, we prepare by moving all possible timer configuration logic
      out of the hyp code.  All virtual timer registers can be programmed from
      EL1 and since the arch timer is always a level triggered interrupt we
      can safely do this with interrupts disabled in the host kernel on the
      way to the guest without taking vtimer interrupts in the host kernel
      (yet).
      
      The downside is that the cntvoff register can only be programmed from
      hyp mode, so we jump into hyp mode and back to program it.  This is also
      safe, because the host kernel doesn't use the virtual timer in the KVM
      code.  It may add a little performance performance penalty, but only
      until following commits where we move this operation to vcpu load/put.
      Signed-off-by: NChristoffer Dall <cdall@linaro.org>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      688c50aa
  14. 03 11月, 2017 2 次提交
    • D
      arm64/sve: KVM: Prevent guests from using SVE · 17eed27b
      Dave Martin 提交于
      Until KVM has full SVE support, guests must not be allowed to
      execute SVE instructions.
      
      This patch enables the necessary traps, and also ensures that the
      traps are disabled again on exit from the guest so that the host
      can still use SVE if it wants to.
      
      On guest exit, high bits of the SVE Zn registers may have been
      clobbered as a side-effect the execution of FPSIMD instructions in
      the guest.  The existing KVM host FPSIMD restore code is not
      sufficient to restore these bits, so this patch explicitly marks
      the CPU as not containing cached vector state for any task, thus
      forcing a reload on the next return to userspace.  This is an
      interim measure, in advance of adding full SVE awareness to KVM.
      
      This marking of cached vector state in the CPU as invalid is done
      using __this_cpu_write(fpsimd_last_state, NULL) in fpsimd.c.  Due
      to the repeated use of this rather obscure operation, it makes
      sense to factor it out as a separate helper with a clearer name.
      This patch factors it out as fpsimd_flush_cpu_state(), and ports
      all callers to use it.
      
      As a side effect of this refactoring, a this_cpu_write() in
      fpsimd_cpu_pm_notifier() is changed to __this_cpu_write().  This
      should be fine, since cpu_pm_enter() is supposed to be called only
      with interrupts disabled.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      17eed27b
    • D
      arm64: KVM: Hide unsupported AArch64 CPU features from guests · 93390c0a
      Dave Martin 提交于
      Currently, a guest kernel sees the true CPU feature registers
      (ID_*_EL1) when it reads them using MRS instructions.  This means
      that the guest may observe features that are present in the
      hardware but the host doesn't understand or doesn't provide support
      for.  A guest may legimitately try to use such a feature as per the
      architecture, but use of the feature may trap instead of working
      normally, triggering undef injection into the guest.
      
      This is not a problem for the host, but the guest may go wrong when
      running on newer hardware than the host knows about.
      
      This patch hides from guest VMs any AArch64-specific CPU features
      that the host doesn't support, by exposing to the guest the
      sanitised versions of the registers computed by the cpufeatures
      framework, instead of the true hardware registers.  To achieve
      this, HCR_EL2.TID3 is now set for AArch64 guests, and emulation
      code is added to KVM to report the sanitised versions of the
      affected registers in response to MRS and register reads from
      userspace.
      
      The affected registers are removed from invariant_sys_regs[] (since
      the invariant_sys_regs handling is no longer quite correct for
      them) and added to sys_reg_desgs[], with appropriate access(),
      get_user() and set_user() methods.  No runtime vcpu storage is
      allocated for the registers: instead, they are read on demand from
      the cpufeatures framework.  This may need modification in the
      future if there is a need for userspace to customise the features
      visible to the guest.
      
      Attempts by userspace to write the registers are handled similarly
      to the current invariant_sys_regs handling: writes are permitted,
      but only if they don't attempt to change the value.  This is
      sufficient to support VM snapshot/restore from userspace.
      
      Because of the additional registers, restoring a VM on an older
      kernel may not work unless userspace knows how to handle the extra
      VM registers exposed to the KVM user ABI by this patch.
      
      Under the principle of least damage, this patch makes no attempt to
      handle any of the other registers currently in
      invariant_sys_regs[], or to emulate registers for AArch32: however,
      these could be handled in a similar way in future, as necessary.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      93390c0a