1. 18 Apr, 2019 13 commits
    • Dave Martin's avatar
      KVM: Clarify KVM_{SET,GET}_ONE_REG error code documentation · fe365b4e
      Dave Martin authored
      The current error code documentation for KVM_GET_ONE_REG and
      KVM_SET_ONE_REG could be read as implying that all architectures
      implement these error codes, or that KVM guarantees which error
      code is returned in a particular situation.
      
      Because this is not really the case, this patch waters down the
      documentation explicitly to remove such guarantees.
      
      EPERM is marked as arm64-specific, since for now arm64 really is
      the only architecture that yields this error code for the
      finalization-required case.  Keeping this as a distinct error code
      is useful however for debugging due to the statefulness of the API
      in this instance.
      
      No functional change.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Fixes: 395f562f ("KVM: Document errors for KVM_GET_ONE_REG and KVM_SET_ONE_REG")
      Fixes: 50036ad0 ("KVM: arm64/sve: Document KVM API extensions for SVE")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      fe365b4e
    • Dave Martin's avatar
      KVM: Clarify capability requirements for KVM_ARM_VCPU_FINALIZE · 9df2d660
      Dave Martin authored
      Userspace is only supposed to use KVM_ARM_VCPU_FINALIZE when there
      is some vcpu feature that can actually be finalized.
      
      This means that documenting KVM_ARM_VCPU_FINALIZE as available or
      not depending on the capabilities present is not helpful.
      
      This patch amends the documentation to describe availability in
      terms of which capability is required for each finalizable feature
      instead.
      
      In any case, userspace sees the same error (EINVAL) regardless of
      whether the given feature is not present or KVM_ARM_VCPU_FINALIZE
      is not implemented at all.
      
      No functional change.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      9df2d660
    • Dave Martin's avatar
      KVM: arm/arm64: Clean up vcpu finalization function parameter naming · 92e68b2b
      Dave Martin authored
      Currently, the internal vcpu finalization functions use a different
      name ("what") for the feature parameter than the name ("feature")
      used in the documentation.
      
      To avoid future confusion, this patch converts everything to use
      the name "feature" consistently.
      
      No functional change.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      92e68b2b
    • Dave Martin's avatar
      KVM: arm64/sve: Explain validity checks in set_sve_vls() · ecfb6ed4
      Dave Martin authored
      Correct virtualization of SVE relies for correctness on code in
      set_sve_vls() that verifies consistency between the set of vector
      lengths requested by userspace and the set of vector lengths
      available on the host.
      
      However, the purpose of this code is not obvious, and not likely to
      be apparent at all to people who do not have detailed knowledge of
      the SVE system-level architecture.
      
      This patch adds a suitable comment to explain what these checks are
      for.
      
      No functional change.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      ecfb6ed4
    • Dave Martin's avatar
      KVM: arm64/sve: Simplify KVM_REG_ARM64_SVE_VLS array sizing · 4bd774e5
      Dave Martin authored
      A complicated DIV_ROUND_UP() expression is currently written out
      explicitly in multiple places in order to specify the size of the
      bitmap exchanged with userspace to represent the value of the
      KVM_REG_ARM64_SVE_VLS pseudo-register.
      
      Userspace currently has no direct way to work this out either: for
      documentation purposes, the size is just quoted as 8 u64s.
      
      To make this more intuitive, this patch replaces these with a
      single define, which is also exported to userspace as
      KVM_ARM64_SVE_VLS_WORDS.
      
      Since the number of words in a bitmap is just the index of the last
      word used + 1, this patch expresses the bound that way instead.
      This should make it clearer what is being expressed.
      
      For userspace convenience, the minimum and maximum possible vector
      lengths relevant to the KVM ABI are exposed to UAPI as
      KVM_ARM64_SVE_VQ_MIN, KVM_ARM64_SVE_VQ_MAX.  Since the only direct
      use for these at present is manipulation of KVM_REG_ARM64_SVE_VLS,
      no corresponding _VL_ macros are defined.  They could be added
      later if a need arises.
      
      Since use of DIV_ROUND_UP() was the only reason for including
      <linux/kernel.h> in guest.c, this patch also removes that #include.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      4bd774e5
    • Dave Martin's avatar
      KVM: arm64/sve: WARN when avoiding divide-by-zero in sve_reg_to_region() · 55ffad3b
      Dave Martin authored
      sve_reg_to_region() currently passes the result of
      vcpu_sve_state_size() to array_index_nospec(), effectively
      leading to a divide / modulo operation.
      
      Currently the code bails out and returns -EINVAL if
      vcpu_sve_state_size() turns out to be zero, in order to avoid going
      ahead and attempting to divide by zero.  This is reasonable, but it
      should only happen if the kernel contains some other bug that
      allowed this code to be reached without the vcpu having been
      properly initialised.
      
      To make it clear that this is a defence against bugs rather than
      something that the user should be able to trigger, this patch marks
      the check with WARN_ON().
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      55ffad3b
    • Dave Martin's avatar
      KVM: arm64/sve: Make register ioctl access errors more consistent · 52110aa9
      Dave Martin authored
      Currently, the way error codes are generated when processing the
      SVE register access ioctls in a bit haphazard.
      
      This patch refactors the code so that the behaviour is more
      consistent: now, -EINVAL should be returned only for unrecognised
      register IDs or when some other runtime error occurs.  -ENOENT is
      returned for register IDs that are recognised, but whose
      corresponding register (or slice) does not exist for the vcpu.
      
      To this end, in {get,set}_sve_reg() we now delegate the
      vcpu_has_sve() check down into {get,set}_sve_vls() and
      sve_reg_to_region().  The KVM_REG_ARM64_SVE_VLS special case is
      picked off first, then sve_reg_to_region() plays the role of
      exhaustively validating or rejecting the register ID and (where
      accepted) computing the applicable register region as before.
      
      sve_reg_to_region() is rearranged so that -ENOENT or -EPERM is not
      returned prematurely, before checking whether reg->id is in a
      recognised range.
      
      -EPERM is now only returned when an attempt is made to access an
      actually existing register slice on an unfinalized vcpu.
      
      Fixes: e1c9c983 ("KVM: arm64/sve: Add SVE support to register access ioctl interface")
      Fixes: 9033bba4 ("KVM: arm64/sve: Add pseudo-register for the guest's vector lengths")
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      52110aa9
    • Dave Martin's avatar
      KVM: arm64/sve: Miscellaneous tidyups in guest.c · f8d4635a
      Dave Martin authored
       * Remove a few redundant blank lines that are stylistically
         inconsistent with code already in guest.c and are just taking up
         space.
      
       * Delete a couple of pointless empty default cases from switch
         statements whose behaviour is otherwise obvious anyway.
      
       * Fix some typos and consolidate some redundantly duplicated
         comments.
      
       * Respell the slice index check in sve_reg_to_region() as "> 0"
         to be more consistent with what is logically being checked here
         (i.e., "is the slice index too large"), even though we don't try
         to cope with multiple slices yet.
      
      No functional change.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      f8d4635a
    • Dave Martin's avatar
      KVM: arm64/sve: Clean up UAPI register ID definitions · 8ae6efdd
      Dave Martin authored
      Currently, the SVE register ID macros are not all defined in the
      same way, and advertise the fact that FFR maps onto the nonexistent
      predicate register P16.  This is really just for kernel
      convenience, and may lead userspace into bad habits.
      
      Instead, this patch masks the ID macro arguments so that
      architecturally invalid register numbers will not be passed through
      any more, and uses a literal KVM_REG_ARM64_SVE_FFR_BASE macro to
      define KVM_REG_ARM64_SVE_FFR(), similarly to the way the _ZREG()
      and _PREG() macros are defined.
      
      Rather than plugging in magic numbers for the number of Z- and P-
      registers and the maximum possible number of register slices, this
      patch provides definitions for those too.  Userspace is going to
      need them in any case, and it makes sense for them to come from
      <uapi/asm/kvm.h>.
      
      sve_reg_to_region() uses convenience constants that are defined in
      a different way, and also makes use of the fact that the FFR IDs
      are really contiguous with the P15 IDs, so this patch retains the
      existing convenience constants in guest.c, supplemented with a
      couple of sanity checks to check for consistency with the UAPI
      header.
      
      Fixes: e1c9c983 ("KVM: arm64/sve: Add SVE support to register access ioctl interface")
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      8ae6efdd
    • Dave Martin's avatar
      KVM: arm64/sve: sys_regs: Demote redundant vcpu_has_sve() checks to WARNs · 700698a8
      Dave Martin authored
      Because of the logic in kvm_arm_sys_reg_{get,set}_reg() and
      sve_id_visibility(), we should never call
      {get,set}_id_aa64zfr0_el1() for a vcpu where !vcpu_has_sve(vcpu).
      
      To avoid the code giving the impression that it is valid for these
      functions to be called in this situation, and to help the compiler
      make the right optimisation decisions, this patch adds WARN_ON()
      for these cases.
      
      Given the way the logic is spread out, this seems preferable to
      dropping the checks altogether.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      700698a8
    • Dave Martin's avatar
      KVM: arm: Make vcpu finalization stubs into inline functions · 0323e027
      Dave Martin authored
      The vcpu finalization stubs kvm_arm_vcpu_finalize() and
      kvm_arm_vcpu_is_finalized() are currently #defines for ARM, which
      limits the type-checking that the compiler can do at runtime.
      
      The only reason for them to be #defines was to avoid reliance on
      the definition of struct kvm_vcpu, which is not available here due
      to circular #include problems.  However, because these are stubs
      containing no code, they don't need the definition of struct
      kvm_vcpu after all; only a declaration is needed (which is
      available already).
      
      So in the interests of cleanliness, this patch converts them to
      inline functions.
      
      No functional change.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      0323e027
    • Dave Martin's avatar
      KVM: arm/arm64: Demote kvm_arm_init_arch_resources() to just set up SVE · a3be836d
      Dave Martin authored
      The introduction of kvm_arm_init_arch_resources() looks like
      premature factoring, since nothing else uses this hook yet and it
      is not clear what will use it in the future.
      
      For now, let's not pretend that this is a general thing:
      
      This patch simply renames the function to kvm_arm_init_sve(),
      retaining the arm stub version under the new name.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      a3be836d
    • Dave Martin's avatar
      arm64/sve: Clarify vq map semantics · 624835ab
      Dave Martin authored
      Currently the meanings of sve_vq_map and the ancillary helpers
      __bit_to_vq() and __vq_to_bit() are not clearly explained.
      
      This patch makes the explanatory comment clearer, and removes the
      duplicate comment from fpsimd.h.
      
      The WARN_ON() currently present in __bit_to_vq() confuses the
      intended use of this helper.  Since these are low-level helpers not
      intended for general-purpose use anyway, it is better not to make
      guesses about how these functions will be used: rather, this patch
      removes the WARN_ON() and relies on callers to use the helpers
      sensibly.
      Suggested-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      624835ab
  2. 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
  3. 29 Mar, 2019 26 commits