1. 03 11月, 2017 1 次提交
    • 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
  2. 15 6月, 2017 1 次提交
  3. 16 5月, 2017 1 次提交
  4. 03 2月, 2017 1 次提交
    • W
      arm64: KVM: Save/restore the host SPE state when entering/leaving a VM · f85279b4
      Will Deacon 提交于
      The SPE buffer is virtually addressed, using the page tables of the CPU
      MMU. Unusually, this means that the EL0/1 page table may be live whilst
      we're executing at EL2 on non-VHE configurations. When VHE is in use,
      we can use the same property to profile the guest behind its back.
      
      This patch adds the relevant disabling and flushing code to KVM so that
      the host can make use of SPE without corrupting guest memory, and any
      attempts by a guest to use SPE will result in a trap.
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      f85279b4
  5. 09 12月, 2016 1 次提交
    • M
      arm64: KVM: pmu: Reset PMSELR_EL0.SEL to a sane value before entering the guest · 21cbe3cc
      Marc Zyngier 提交于
      The ARMv8 architecture allows the cycle counter to be configured
      by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
      hence accessing PMCCFILTR_EL0. But it disallows the use of
      PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
      PMXEVCNTR_EL0.
      
      Linux itself doesn't violate this rule, but we may end up with
      PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
      guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
      despite the guest not having done anything wrong.
      
      In order to avoid this unfortunate course of events (haha!), let's
      sanitize PMSELR_EL0 on guest entry. This ensures that the guest
      won't explode unexpectedly.
      
      Cc: stable@vger.kernel.org #4.6+
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      21cbe3cc
  6. 17 11月, 2016 1 次提交
    • S
      arm64: Support systems without FP/ASIMD · 82e0191a
      Suzuki K Poulose 提交于
      The arm64 kernel assumes that FP/ASIMD units are always present
      and accesses the FP/ASIMD specific registers unconditionally. This
      could cause problems when they are absent. This patch adds the
      support for kernel handling systems without FP/ASIMD by skipping the
      register access within the kernel. For kvm, we trap the accesses
      to FP/ASIMD and inject an undefined instruction exception to the VM.
      
      The callers of the exported kernel_neon_begin_partial() should
      make sure that the FP/ASIMD is supported.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      [catalin.marinas@arm.com: add comment on the ARM64_HAS_NO_FPSIMD conflict and the new location]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      82e0191a
  7. 22 9月, 2016 1 次提交
    • V
      arm64: KVM: Use static keys for selecting the GIC backend · 5a7a8426
      Vladimir Murzin 提交于
      Currently GIC backend is selected via alternative framework and this
      is fine. We are going to introduce vgic-v3 to 32-bit world and there
      we don't have patching framework in hand, so we can either check
      support for GICv3 every time we need to choose which backend to use or
      try to optimise it by using static keys. The later looks quite
      promising because we can share logic involved in selecting GIC backend
      between architectures if both uses static keys.
      
      This patch moves arm64 from alternative to static keys framework for
      selecting GIC backend. For that we embed static key into vgic_global
      and enable the key during vgic initialisation based on what has
      already been exposed by the host GIC driver.
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
      5a7a8426
  8. 08 9月, 2016 5 次提交
  9. 17 8月, 2016 1 次提交
  10. 04 7月, 2016 1 次提交
  11. 22 6月, 2016 1 次提交
  12. 01 3月, 2016 7 次提交
  13. 25 1月, 2016 1 次提交
  14. 14 12月, 2015 5 次提交