Commit a87a3643 authored by Oliver Upton's avatar Oliver Upton
Browse files

Merge branch kvm-arm64/writable-id-regs into kvmarm/next



* kvm-arm64/writable-id-regs:
  : Writable ID registers, courtesy of Jing Zhang
  :
  : This series significantly expands the architectural feature set that
  : userspace can manipulate via the ID registers. A new ioctl is defined
  : that makes the mutable fields in the ID registers discoverable to
  : userspace.
  KVM: selftests: Avoid using forced target for generating arm64 headers
  tools headers arm64: Fix references to top srcdir in Makefile
  KVM: arm64: selftests: Test for setting ID register from usersapce
  tools headers arm64: Update sysreg.h with kernel sources
  KVM: selftests: Generate sysreg-defs.h and add to include path
  perf build: Generate arm64's sysreg-defs.h and add to include path
  tools: arm64: Add a Makefile for generating sysreg-defs.h
  KVM: arm64: Document vCPU feature selection UAPIs
  KVM: arm64: Allow userspace to change ID_AA64ZFR0_EL1
  KVM: arm64: Allow userspace to change ID_AA64PFR0_EL1
  KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1
  KVM: arm64: Allow userspace to change ID_AA64ISAR{0-2}_EL1
  KVM: arm64: Bump up the default KVM sanitised debug version to v8p8
  KVM: arm64: Reject attempts to set invalid debug arch version
  KVM: arm64: Advertise selected DebugVer in DBGDIDR.Version
  KVM: arm64: Use guest ID register values for the sake of emulation
  KVM: arm64: Document KVM_ARM_GET_REG_WRITABLE_MASKS
  KVM: arm64: Allow userspace to get the writable masks for feature ID registers

Signed-off-by: default avatarOliver Upton <oliver.upton@linux.dev>
parents 54b44ad2 70c7b704
Loading
Loading
Loading
Loading
+52 −0
Original line number Diff line number Diff line
@@ -3370,6 +3370,8 @@ return indicates the attribute is implemented. It does not necessarily
indicate that the attribute can be read or written in the device's
current state.  "addr" is ignored.

.. _KVM_ARM_VCPU_INIT:

4.82 KVM_ARM_VCPU_INIT
----------------------

@@ -6070,6 +6072,56 @@ writes to the CNTVCT_EL0 and CNTPCT_EL0 registers using the SET_ONE_REG
interface. No error will be returned, but the resulting offset will not be
applied.

.. _KVM_ARM_GET_REG_WRITABLE_MASKS:

4.139 KVM_ARM_GET_REG_WRITABLE_MASKS
-------------------------------------------

:Capability: KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES
:Architectures: arm64
:Type: vm ioctl
:Parameters: struct reg_mask_range (in/out)
:Returns: 0 on success, < 0 on error


::

        #define KVM_ARM_FEATURE_ID_RANGE	0
        #define KVM_ARM_FEATURE_ID_RANGE_SIZE	(3 * 8 * 8)

        struct reg_mask_range {
                __u64 addr;             /* Pointer to mask array */
                __u32 range;            /* Requested range */
                __u32 reserved[13];
        };

This ioctl copies the writable masks for a selected range of registers to
userspace.

The ``addr`` field is a pointer to the destination array where KVM copies
the writable masks.

The ``range`` field indicates the requested range of registers.
``KVM_CHECK_EXTENSION`` for the ``KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES``
capability returns the supported ranges, expressed as a set of flags. Each
flag's bit index represents a possible value for the ``range`` field.
All other values are reserved for future use and KVM may return an error.

The ``reserved[13]`` array is reserved for future use and should be 0, or
KVM may return an error.

KVM_ARM_FEATURE_ID_RANGE (0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The Feature ID range is defined as the AArch64 System register space with
op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}.

The mask returned array pointed to by ``addr`` is indexed by the macro
``ARM64_FEATURE_ID_RANGE_IDX(op0, op1, crn, crm, op2)``, allowing userspace
to know what fields can be changed for the system register described by
``op0, op1, crn, crm, op2``. KVM rejects ID register values that describe a
superset of the features supported by the system.

5. The kvm_run structure
========================

+1 −0
Original line number Diff line number Diff line
@@ -11,3 +11,4 @@ ARM
   hypercalls
   pvtime
   ptp_kvm
   vcpu-features
+48 −0
Original line number Diff line number Diff line
.. SPDX-License-Identifier: GPL-2.0

===============================
vCPU feature selection on arm64
===============================

KVM/arm64 provides two mechanisms that allow userspace to configure
the CPU features presented to the guest.

KVM_ARM_VCPU_INIT
=================

The ``KVM_ARM_VCPU_INIT`` ioctl accepts a bitmap of feature flags
(``struct kvm_vcpu_init::features``). Features enabled by this interface are
*opt-in* and may change/extend UAPI. See :ref:`KVM_ARM_VCPU_INIT` for complete
documentation of the features controlled by the ioctl.

Otherwise, all CPU features supported by KVM are described by the architected
ID registers.

The ID Registers
================

The Arm architecture specifies a range of *ID Registers* that describe the set
of architectural features supported by the CPU implementation. KVM initializes
the guest's ID registers to the maximum set of CPU features supported by the
system. The ID register values may be VM-scoped in KVM, meaning that the
values could be shared for all vCPUs in a VM.

KVM allows userspace to *opt-out* of certain CPU features described by the ID
registers by writing values to them via the ``KVM_SET_ONE_REG`` ioctl. The ID
registers are mutable until the VM has started, i.e. userspace has called
``KVM_RUN`` on at least one vCPU in the VM. Userspace can discover what fields
are mutable in the ID registers using the ``KVM_ARM_GET_REG_WRITABLE_MASKS``.
See the :ref:`ioctl documentation <KVM_ARM_GET_REG_WRITABLE_MASKS>` for more
details.

Userspace is allowed to *limit* or *mask* CPU features according to the rules
outlined by the architecture in DDI0487J.a D19.1.3 'Principles of the ID
scheme for fields in ID register'. KVM does not allow ID register values that
exceed the capabilities of the system.

.. warning::
   It is **strongly recommended** that userspace modify the ID register values
   before accessing the rest of the vCPU's CPU register state. KVM may use the
   ID register values to control feature emulation. Interleaving ID register
   modification with other system register accesses may lead to unpredictable
   behavior.
+2 −0
Original line number Diff line number Diff line
@@ -1108,6 +1108,8 @@ int kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
			       struct kvm_arm_copy_mte_tags *copy_tags);
int kvm_vm_ioctl_set_counter_offset(struct kvm *kvm,
				    struct kvm_arm_counter_offset *offset);
int kvm_vm_ioctl_get_reg_writable_masks(struct kvm *kvm,
					struct reg_mask_range *range);

/* Guest/host FPSIMD coordination helpers */
int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu);
+32 −0
Original line number Diff line number Diff line
@@ -505,6 +505,38 @@ struct kvm_smccc_filter {
#define KVM_HYPERCALL_EXIT_SMC		(1U << 0)
#define KVM_HYPERCALL_EXIT_16BIT	(1U << 1)

/*
 * Get feature ID registers userspace writable mask.
 *
 * From DDI0487J.a, D19.2.66 ("ID_AA64MMFR2_EL1, AArch64 Memory Model
 * Feature Register 2"):
 *
 * "The Feature ID space is defined as the System register space in
 * AArch64 with op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7},
 * op2=={0-7}."
 *
 * This covers all currently known R/O registers that indicate
 * anything useful feature wise, including the ID registers.
 *
 * If we ever need to introduce a new range, it will be described as
 * such in the range field.
 */
#define KVM_ARM_FEATURE_ID_RANGE_IDX(op0, op1, crn, crm, op2)		\
	({								\
		__u64 __op1 = (op1) & 3;				\
		__op1 -= (__op1 == 3);					\
		(__op1 << 6 | ((crm) & 7) << 3 | (op2));		\
	})

#define KVM_ARM_FEATURE_ID_RANGE	0
#define KVM_ARM_FEATURE_ID_RANGE_SIZE	(3 * 8 * 8)

struct reg_mask_range {
	__u64 addr;		/* Pointer to mask array */
	__u32 range;		/* Requested range */
	__u32 reserved[13];
};

#endif

#endif /* __ARM_KVM_H__ */
Loading