1. 24 Apr, 2019 5 commits
    • Andrew Murray's avatar
      arm64: KVM: Encapsulate kvm_cpu_context in kvm_host_data · 630a1685
      Andrew Murray authored
      The virt/arm core allocates a kvm_cpu_context_t percpu, at present this is
      a typedef to kvm_cpu_context and is used to store host cpu context. The
      kvm_cpu_context structure is also used elsewhere to hold vcpu context.
      In order to use the percpu to hold additional future host information we
      encapsulate kvm_cpu_context in a new structure and rename the typedef and
      percpu to match.
      Signed-off-by: default avatarAndrew Murray <andrew.murray@arm.com>
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      630a1685
    • Andrew Murray's avatar
      arm64: arm_pmu: Remove unnecessary isb instruction · 21bb0ebf
      Andrew Murray authored
      The armv8pmu_enable_event_counter function issues an isb instruction
      after enabling a pair of counters - this doesn't provide any value
      and is inconsistent with the armv8pmu_disable_event_counter.
      
      In any case armv8pmu_enable_event_counter is always called with the
      PMU stopped. Starting the PMU with armv8pmu_start results in an isb
      instruction being issued prior to writing to PMCR_EL0.
      
      Let's remove the unnecessary isb instruction.
      Signed-off-by: default avatarAndrew Murray <andrew.murray@arm.com>
      Reviewed-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      21bb0ebf
    • Amit Daniel Kachhap's avatar
      KVM: arm64: Add capability to advertise ptrauth for guest · a243c16d
      Amit Daniel Kachhap authored
      This patch advertises the capability of two cpu feature called address
      pointer authentication and generic pointer authentication. These
      capabilities depend upon system support for pointer authentication and
      VHE mode.
      
      The current arm64 KVM partially implements pointer authentication and
      support of address/generic authentication are tied together. However,
      separate ABI requirements for both of them is added so that any future
      isolated implementation will not require any ABI changes.
      Signed-off-by: default avatarAmit Daniel Kachhap <amit.kachhap@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <christoffer.dall@arm.com>
      Cc: kvmarm@lists.cs.columbia.edu
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      a243c16d
    • Amit Daniel Kachhap's avatar
      KVM: arm64: Add userspace flag to enable pointer authentication · a22fa321
      Amit Daniel Kachhap authored
      Now that the building blocks of pointer authentication are present, lets
      add userspace flags KVM_ARM_VCPU_PTRAUTH_ADDRESS and
      KVM_ARM_VCPU_PTRAUTH_GENERIC. These flags will enable pointer
      authentication for the KVM guest on a per-vcpu basis through the ioctl
      KVM_ARM_VCPU_INIT.
      
      This features will allow the KVM guest to allow the handling of
      pointer authentication instructions or to treat them as undefined
      if not set.
      
      Necessary documentations are added to reflect the changes done.
      Reviewed-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarAmit Daniel Kachhap <amit.kachhap@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Christoffer Dall <christoffer.dall@arm.com>
      Cc: kvmarm@lists.cs.columbia.edu
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      a22fa321
    • Mark Rutland's avatar
      KVM: arm/arm64: Context-switch ptrauth registers · 384b40ca
      Mark Rutland authored
      When pointer authentication is supported, a guest may wish to use it.
      This patch adds the necessary KVM infrastructure for this to work, with
      a semi-lazy context switch of the pointer auth state.
      
      Pointer authentication feature is only enabled when VHE is built
      in the kernel and present in the CPU implementation so only VHE code
      paths are modified.
      
      When we schedule a vcpu, we disable guest usage of pointer
      authentication instructions and accesses to the keys. While these are
      disabled, we avoid context-switching the keys. When we trap the guest
      trying to use pointer authentication functionality, we change to eagerly
      context-switching the keys, and enable the feature. The next time the
      vcpu is scheduled out/in, we start again. However the host key save is
      optimized and implemented inside ptrauth instruction/register access
      trap.
      
      Pointer authentication consists of address authentication and generic
      authentication, and CPUs in a system might have varied support for
      either. Where support for either feature is not uniform, it is hidden
      from guests via ID register emulation, as a result of the cpufeature
      framework in the host.
      
      Unfortunately, address authentication and generic authentication cannot
      be trapped separately, as the architecture provides a single EL2 trap
      covering both. If we wish to expose one without the other, we cannot
      prevent a (badly-written) guest from intermittently using a feature
      which is not uniformly supported (when scheduled on a physical CPU which
      supports the relevant feature). Hence, this patch expects both type of
      authentication to be present in a cpu.
      
      This switch of key is done from guest enter/exit assembly as preparation
      for the upcoming in-kernel pointer authentication support. Hence, these
      key switching routines are not implemented in C code as they may cause
      pointer authentication key signing error in some situations.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      [Only VHE, key switch in full assembly, vcpu_has_ptrauth checks
      , save host key in ptrauth exception trap]
      Signed-off-by: default avatarAmit Daniel Kachhap <amit.kachhap@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Cc: Christoffer Dall <christoffer.dall@arm.com>
      Cc: kvmarm@lists.cs.columbia.edu
      [maz: various fixups]
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      384b40ca
  2. 23 Apr, 2019 1 commit
  3. 18 Apr, 2019 14 commits
  4. 02 Apr, 2019 1 commit
    • Marc Zyngier's avatar
      arm64: KVM: Fix system register enumeration · 5d8d4af2
      Marc Zyngier authored
      The introduction of the SVE registers to userspace started with a
      refactoring of the way we expose any register via the ONE_REG
      interface.
      
      Unfortunately, this change doesn't exactly behave as expected
      if the number of registers is non-zero and consider everything
      to be an error. The visible result is that QEMU barfs very early
      when creating vcpus.
      
      Make sure we only exit early in case there is an actual error, rather
      than a positive number of registers...
      
      Fixes: be25bbb3 ("KVM: arm64: Factor out core register ID enumeration")
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      5d8d4af2
  5. 29 Mar, 2019 19 commits
    • Dave Martin's avatar
      KVM: arm64/sve: Document KVM API extensions for SVE · 50036ad0
      Dave Martin authored
      This patch adds sections to the KVM API documentation describing
      the extensions for supporting the Scalable Vector Extension (SVE)
      in guests.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      50036ad0
    • Dave Martin's avatar
      KVM: Document errors for KVM_GET_ONE_REG and KVM_SET_ONE_REG · 395f562f
      Dave Martin authored
      KVM_GET_ONE_REG and KVM_SET_ONE_REG return some error codes that
      are not documented (but hopefully not surprising either).  To give
      an indication of what these may mean, this patch adds brief
      documentation.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      395f562f
    • Dave Martin's avatar
      KVM: arm64: Add a capability to advertise SVE support · 555f3d03
      Dave Martin authored
      To provide a uniform way to check for KVM SVE support amongst other
      features, this patch adds a suitable capability KVM_CAP_ARM_SVE,
      and reports it as present when SVE is available.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      555f3d03
    • Dave Martin's avatar
      KVM: arm64/sve: Allow userspace to enable SVE for vcpus · 9a3cdf26
      Dave Martin authored
      Now that all the pieces are in place, this patch offers a new flag
      KVM_ARM_VCPU_SVE that userspace can pass to KVM_ARM_VCPU_INIT to
      turn on SVE for the guest, on a per-vcpu basis.
      
      As part of this, support for initialisation and reset of the SVE
      vector length set and registers is added in the appropriate places,
      as well as finally setting the KVM_ARM64_GUEST_HAS_SVE vcpu flag,
      to turn on the SVE support code.
      
      Allocation of the SVE register storage in vcpu->arch.sve_state is
      deferred until the SVE configuration is finalized, by which time
      the size of the registers is known.
      
      Setting the vector lengths supported by the vcpu is considered
      configuration of the emulated hardware rather than runtime
      configuration, so no support is offered for changing the vector
      lengths available to an existing vcpu across reset.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      9a3cdf26
    • Dave Martin's avatar
      KVM: arm64/sve: Add pseudo-register for the guest's vector lengths · 9033bba4
      Dave Martin authored
      This patch adds a new pseudo-register KVM_REG_ARM64_SVE_VLS to
      allow userspace to set and query the set of vector lengths visible
      to the guest.
      
      In the future, multiple register slices per SVE register may be
      visible through the ioctl interface.  Once the set of slices has
      been determined we would not be able to allow the vector length set
      to be changed any more, in order to avoid userspace seeing
      inconsistent sets of registers.  For this reason, this patch adds
      support for explicit finalization of the SVE configuration via the
      KVM_ARM_VCPU_FINALIZE ioctl.
      
      Finalization is the proper place to allocate the SVE register state
      storage in vcpu->arch.sve_state, so this patch adds that as
      appropriate.  The data is freed via kvm_arch_vcpu_uninit(), which
      was previously a no-op on arm64.
      
      To simplify the logic for determining what vector lengths can be
      supported, some code is added to KVM init to work this out, in the
      kvm_arm_init_arch_resources() hook.
      
      The KVM_REG_ARM64_SVE_VLS pseudo-register is not exposed yet.
      Subsequent patches will allow SVE to be turned on for guest vcpus,
      making it visible.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      9033bba4
    • Dave Martin's avatar
      KVM: arm/arm64: Add KVM_ARM_VCPU_FINALIZE ioctl · 7dd32a0d
      Dave Martin authored
      Some aspects of vcpu configuration may be too complex to be
      completed inside KVM_ARM_VCPU_INIT.  Thus, there may be a
      requirement for userspace to do some additional configuration
      before various other ioctls will work in a consistent way.
      
      In particular this will be the case for SVE, where userspace will
      need to negotiate the set of vector lengths to be made available to
      the guest before the vcpu becomes fully usable.
      
      In order to provide an explicit way for userspace to confirm that
      it has finished setting up a particular vcpu feature, this patch
      adds a new ioctl KVM_ARM_VCPU_FINALIZE.
      
      When userspace has opted into a feature that requires finalization,
      typically by means of a feature flag passed to KVM_ARM_VCPU_INIT, a
      matching call to KVM_ARM_VCPU_FINALIZE is now required before
      KVM_RUN or KVM_GET_REG_LIST is allowed.  Individual features may
      impose additional restrictions where appropriate.
      
      No existing vcpu features are affected by this, so current
      userspace implementations will continue to work exactly as before,
      with no need to issue KVM_ARM_VCPU_FINALIZE.
      
      As implemented in this patch, KVM_ARM_VCPU_FINALIZE is currently a
      placeholder: no finalizable features exist yet, so ioctl is not
      required and will always yield EINVAL.  Subsequent patches will add
      the finalization logic to make use of this ioctl for SVE.
      
      No functional change for existing userspace.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      7dd32a0d
    • Dave Martin's avatar
      KVM: arm/arm64: Add hook for arch-specific KVM initialisation · 0f062bfe
      Dave Martin authored
      This patch adds a kvm_arm_init_arch_resources() hook to perform
      subarch-specific initialisation when starting up KVM.
      
      This will be used in a subsequent patch for global SVE-related
      setup on arm64.
      
      No functional change.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      0f062bfe
    • Dave Martin's avatar
      arm64/sve: In-kernel vector length availability query interface · ead9e430
      Dave Martin authored
      KVM will need to interrogate the set of SVE vector lengths
      available on the system.
      
      This patch exposes the relevant bits to the kernel, along with a
      sve_vq_available() helper to check whether a particular vector
      length is supported.
      
      __vq_to_bit() and __bit_to_vq() are not intended for use outside
      these functions: now that these are exposed outside fpsimd.c, they
      are prefixed with __ in order to provide an extra hint that they
      are not intended for general-purpose use.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      ead9e430
    • Dave Martin's avatar
      KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST · 8e3c54c8
      Dave Martin authored
      This patch includes the SVE register IDs in the list returned by
      KVM_GET_REG_LIST, as appropriate.
      
      On a non-SVE-enabled vcpu, no new IDs are added.
      
      On an SVE-enabled vcpu, IDs for the FPSIMD V-registers are removed
      from the list, since userspace is required to access the Z-
      registers instead in order to access the V-register content.  For
      the variably-sized SVE registers, the appropriate set of slice IDs
      are enumerated, depending on the maximum vector length for the
      vcpu.
      
      As it currently stands, the SVE architecture never requires more
      than one slice to exist per register, so this patch adds no
      explicit support for enumerating multiple slices.  The code can be
      extended straightforwardly to support this in the future, if
      needed.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      8e3c54c8
    • Dave Martin's avatar
      KVM: arm64/sve: Add SVE support to register access ioctl interface · e1c9c983
      Dave Martin authored
      This patch adds the following registers for access via the
      KVM_{GET,SET}_ONE_REG interface:
      
       * KVM_REG_ARM64_SVE_ZREG(n, i) (n = 0..31) (in 2048-bit slices)
       * KVM_REG_ARM64_SVE_PREG(n, i) (n = 0..15) (in 256-bit slices)
       * KVM_REG_ARM64_SVE_FFR(i) (in 256-bit slices)
      
      In order to adapt gracefully to future architectural extensions,
      the registers are logically divided up into slices as noted above:
      the i parameter denotes the slice index.
      
      This allows us to reserve space in the ABI for future expansion of
      these registers.  However, as of today the architecture does not
      permit registers to be larger than a single slice, so no code is
      needed in the kernel to expose additional slices, for now.  The
      code can be extended later as needed to expose them up to a maximum
      of 32 slices (as carved out in the architecture itself) if they
      really exist someday.
      
      The registers are only visible for vcpus that have SVE enabled.
      They are not enumerated by KVM_GET_REG_LIST on vcpus that do not
      have SVE.
      
      Accesses to the FPSIMD registers via KVM_REG_ARM_CORE is not
      allowed for SVE-enabled vcpus: SVE-aware userspace can use the
      KVM_REG_ARM64_SVE_ZREG() interface instead to access the same
      register state.  This avoids some complex and pointless emulation
      in the kernel to convert between the two views of these aliased
      registers.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      e1c9c983
    • Dave Martin's avatar
      KVM: arm64: Reject ioctl access to FPSIMD V-regs on SVE vcpus · 8c86dfe3
      Dave Martin authored
      In order to avoid the pointless complexity of maintaining two ioctl
      register access views of the same data, this patch blocks ioctl
      access to the FPSIMD V-registers on vcpus that support SVE.
      
      This will make it more straightforward to add SVE register access
      support.
      
      Since SVE is an opt-in feature for userspace, this will not affect
      existing users.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      8c86dfe3
    • Dave Martin's avatar
      KVM: arm64: Factor out core register ID enumeration · be25bbb3
      Dave Martin authored
      In preparation for adding logic to filter out some KVM_REG_ARM_CORE
      registers from the KVM_GET_REG_LIST output, this patch factors out
      the core register enumeration into a separate function and rebuilds
      num_core_regs() on top of it.
      
      This may be a little more expensive (depending on how good a job
      the compiler does of specialising the code), but KVM_GET_REG_LIST
      is not a hot path.
      
      This will make it easier to consolidate ID filtering code in one
      place.
      
      No functional change.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      be25bbb3
    • Dave Martin's avatar
      KVM: arm64: Add missing #include of <linux/string.h> in guest.c · dc52f31a
      Dave Martin authored
      arch/arm64/kvm/guest.c uses the string functions, but the
      corresponding header is not included.
      
      We seem to get away with this for now, but for completeness this
      patch adds the #include, in preparation for adding yet more
      memset() calls.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      dc52f31a
    • Dave Martin's avatar
      KVM: Allow 2048-bit register access via ioctl interface · 2b953ea3
      Dave Martin authored
      The Arm SVE architecture defines registers that are up to 2048 bits
      in size (with some possibility of further future expansion).
      
      In order to avoid the need for an excessively large number of
      ioctls when saving and restoring a vcpu's registers, this patch
      adds a #define to make support for individual 2048-bit registers
      through the KVM_{GET,SET}_ONE_REG ioctl interface official.  This
      will allow each SVE register to be accessed in a single call.
      
      There are sufficient spare bits in the register id size field for
      this change, so there is no ABI impact, providing that
      KVM_GET_REG_LIST does not enumerate any 2048-bit register unless
      userspace explicitly opts in to the relevant architecture-specific
      features.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      2b953ea3
    • Dave Martin's avatar
      KVM: arm64/sve: Context switch the SVE registers · b43b5dd9
      Dave Martin authored
      In order to give each vcpu its own view of the SVE registers, this
      patch adds context storage via a new sve_state pointer in struct
      vcpu_arch.  An additional member sve_max_vl is also added for each
      vcpu, to determine the maximum vector length visible to the guest
      and thus the value to be configured in ZCR_EL2.LEN while the vcpu
      is active.  This also determines the layout and size of the storage
      in sve_state, which is read and written by the same backend
      functions that are used for context-switching the SVE state for
      host tasks.
      
      On SVE-enabled vcpus, SVE access traps are now handled by switching
      in the vcpu's SVE context and disabling the trap before returning
      to the guest.  On other vcpus, the trap is not handled and an exit
      back to the host occurs, where the handle_sve() fallback path
      reflects an undefined instruction exception back to the guest,
      consistently with the behaviour of non-SVE-capable hardware (as was
      done unconditionally prior to this patch).
      
      No SVE handling is added on non-VHE-only paths, since VHE is an
      architectural and Kconfig prerequisite of SVE.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      b43b5dd9
    • Dave Martin's avatar
      KVM: arm64/sve: System register context switch and access support · 73433762
      Dave Martin authored
      This patch adds the necessary support for context switching ZCR_EL1
      for each vcpu.
      
      ZCR_EL1 is trapped alongside the FPSIMD/SVE registers, so it makes
      sense for it to be handled as part of the guest FPSIMD/SVE context
      for context switch purposes instead of handling it as a general
      system register.  This means that it can be switched in lazily at
      the appropriate time.  No effort is made to track host context for
      this register, since SVE requires VHE: thus the hosts's value for
      this register lives permanently in ZCR_EL2 and does not alias the
      guest's value at any time.
      
      The Hyp switch and fpsimd context handling code is extended
      appropriately.
      
      Accessors are added in sys_regs.c to expose the SVE system
      registers and ID register fields.  Because these need to be
      conditionally visible based on the guest configuration, they are
      implemented separately for now rather than by use of the generic
      system register helpers.  This may be abstracted better later on
      when/if there are more features requiring this model.
      
      ID_AA64ZFR0_EL1 is RO-RAZ for MRS/MSR when SVE is disabled for the
      guest, but for compatibility with non-SVE aware KVM implementations
      the register should not be enumerated at all for KVM_GET_REG_LIST
      in this case.  For consistency we also reject ioctl access to the
      register.  This ensures that a non-SVE-enabled guest looks the same
      to userspace, irrespective of whether the kernel KVM implementation
      supports SVE.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      73433762
    • Dave Martin's avatar
      KVM: arm64: Support runtime sysreg visibility filtering · 7f34e409
      Dave Martin authored
      Some optional features of the Arm architecture add new system
      registers that are not present in the base architecture.
      
      Where these features are optional for the guest, the visibility of
      these registers may need to depend on some runtime configuration,
      such as a flag passed to KVM_ARM_VCPU_INIT.
      
      For example, ZCR_EL1 and ID_AA64ZFR0_EL1 need to be hidden if SVE
      is not enabled for the guest, even though these registers may be
      present in the hardware and visible to the host at EL2.
      
      Adding special-case checks all over the place for individual
      registers is going to get messy as the number of conditionally-
      visible registers grows.
      
      In order to help solve this problem, this patch adds a new sysreg
      method visibility() that can be used to hook in any needed runtime
      visibility checks.  This method can currently return
      REG_HIDDEN_USER to inhibit enumeration and ioctl access to the
      register for userspace, and REG_HIDDEN_GUEST to inhibit runtime
      access by the guest using MSR/MRS.  Wrappers are added to allow
      these flags to be conveniently queried.
      
      This approach allows a conditionally modified view of individual
      system registers such as the CPU ID registers, in addition to
      completely hiding register where appropriate.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      7f34e409
    • Dave Martin's avatar
      KVM: arm64: Propagate vcpu into read_id_reg() · 1c199913
      Dave Martin authored
      Architecture features that are conditionally visible to the guest
      will require run-time checks in the ID register accessor functions.
      In particular, read_id_reg() will need to perform checks in order
      to generate the correct emulated value for certain ID register
      fields such as ID_AA64PFR0_EL1.SVE for example.
      
      This patch propagates vcpu into read_id_reg() so that future
      patches can add run-time checks on the guest configuration here.
      
      For now, there is no functional change.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      1c199913
    • Dave Martin's avatar
      KVM: arm64: Add a vcpu flag to control SVE visibility for the guest · 1765edba
      Dave Martin authored
      Since SVE will be enabled or disabled on a per-vcpu basis, a flag
      is needed in order to track which vcpus have it enabled.
      
      This patch adds a suitable flag and a helper for checking it.
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Tested-by: default avatarzhang.lei <zhang.lei@jp.fujitsu.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      1765edba