Merge tag 'kvmarm-for-v5.2' of...

Perf Event Attributes

=====================

Author: Andrew Murray <andrew.murray@arm.com>

Date: 2019-03-06

exclude_user

------------

This attribute excludes userspace.

Userspace always runs at EL0 and thus this attribute will exclude EL0.

exclude_kernel

--------------

This attribute excludes the kernel.

The kernel runs at EL2 with VHE and EL1 without. Guest kernels always run

at EL1.

For the host this attribute will exclude EL1 and additionally EL2 on a VHE

system.

For the guest this attribute will exclude EL1. Please note that EL2 is

never counted within a guest.

exclude_hv

----------

This attribute excludes the hypervisor.

For a VHE host this attribute is ignored as we consider the host kernel to

be the hypervisor.

For a non-VHE host this attribute will exclude EL2 as we consider the

hypervisor to be any code that runs at EL2 which is predominantly used for

guest/host transitions.

For the guest this attribute has no effect. Please note that EL2 is

never counted within a guest.

exclude_host / exclude_guest

----------------------------

These attributes exclude the KVM host and guest, respectively.

The KVM host may run at EL0 (userspace), EL1 (non-VHE kernel) and EL2 (VHE

kernel or non-VHE hypervisor).

The KVM guest may run at EL0 (userspace) and EL1 (kernel).

Due to the overlapping exception levels between host and guests we cannot

exclusively rely on the PMU's hardware exception filtering - therefore we

must enable/disable counting on the entry and exit to the guest. This is

performed differently on VHE and non-VHE systems.

For non-VHE systems we exclude EL2 for exclude_host - upon entering and

exiting the guest we disable/enable the event as appropriate based on the

exclude_host and exclude_guest attributes.

For VHE systems we exclude EL1 for exclude_guest and exclude both EL0,EL2

for exclude_host. Upon entering and exiting the guest we modify the event

to include/exclude EL0 as appropriate based on the exclude_host and

exclude_guest attributes.

The statements above also apply when these attributes are used within a

non-VHE guest however please note that EL2 is never counted within a guest.

Accuracy

--------

On non-VHE hosts we enable/disable counters on the entry/exit of host/guest

transition at EL2 - however there is a period of time between

enabling/disabling the counters and entering/exiting the guest. We are

able to eliminate counters counting host events on the boundaries of guest

entry/exit when counting guest events by filtering out EL2 for

exclude_host. However when using !exclude_hv there is a small blackout

window at the guest entry/exit where host events are not captured.

On VHE systems there are no blackout windows.

Virtualization

--------------

Pointer authentication is not currently supported in KVM guests. KVM

will mask the feature bits from ID_AA64ISAR1_EL1, and attempted use of

the feature will result in an UNDEFINED exception being injected into

the guest.

Pointer authentication is enabled in KVM guest when each virtual cpu is

initialised by passing flags KVM_ARM_VCPU_PTRAUTH_[ADDRESS/GENERIC] and

requesting these two separate cpu features to be enabled. The current KVM

guest implementation works by enabling both features together, so both

these userspace flags are checked before enabling pointer authentication.

The separate userspace flag will allow to have no userspace ABI changes

if support is added in the future to allow these two features to be

enabled independently of one another.

As Arm Architecture specifies that Pointer Authentication feature is

implemented along with the VHE feature so KVM arm64 ptrauth code relies

on VHE mode to be present.

Additionally, when these vcpu feature flags are not set then KVM will

filter out the Pointer Authentication system key registers from

KVM_GET/SET_REG_* ioctls and mask those features from cpufeature ID

register. Any attempt to use the Pointer Authentication instructions will

result in an UNDEFINED exception being injected into the guest.

Type: vcpu ioctl

Parameters: struct kvm_one_reg (in)

Returns: 0 on success, negative value on failure

Errors:

  ENOENT:   no such register

  EINVAL:   invalid register ID, or no such register

  EPERM:    (arm64) register access not allowed before vcpu finalization

(These error codes are indicative only: do not rely on a specific error

code being returned in a specific situation.)

struct kvm_one_reg {

       __u64 id;

value in the kvm_regs structure seen as a 32bit array.

  0x60x0 0000 0010 <index into the kvm_regs struct:16>

Specifically:

    Encoding            Register  Bits  kvm_regs member

----------------------------------------------------------------

  0x6030 0000 0010 0000 X0          64  regs.regs[0]

  0x6030 0000 0010 0002 X1          64  regs.regs[1]

    ...

  0x6030 0000 0010 003c X30         64  regs.regs[30]

  0x6030 0000 0010 003e SP          64  regs.sp

  0x6030 0000 0010 0040 PC          64  regs.pc

  0x6030 0000 0010 0042 PSTATE      64  regs.pstate

  0x6030 0000 0010 0044 SP_EL1      64  sp_el1

  0x6030 0000 0010 0046 ELR_EL1     64  elr_el1

  0x6030 0000 0010 0048 SPSR_EL1    64  spsr[KVM_SPSR_EL1] (alias SPSR_SVC)

  0x6030 0000 0010 004a SPSR_ABT    64  spsr[KVM_SPSR_ABT]

  0x6030 0000 0010 004c SPSR_UND    64  spsr[KVM_SPSR_UND]

  0x6030 0000 0010 004e SPSR_IRQ    64  spsr[KVM_SPSR_IRQ]

  0x6060 0000 0010 0050 SPSR_FIQ    64  spsr[KVM_SPSR_FIQ]

  0x6040 0000 0010 0054 V0         128  fp_regs.vregs[0]    (*)

  0x6040 0000 0010 0058 V1         128  fp_regs.vregs[1]    (*)

    ...

  0x6040 0000 0010 00d0 V31        128  fp_regs.vregs[31]   (*)

  0x6020 0000 0010 00d4 FPSR        32  fp_regs.fpsr

  0x6020 0000 0010 00d5 FPCR        32  fp_regs.fpcr

(*) These encodings are not accepted for SVE-enabled vcpus.  See

    KVM_ARM_VCPU_INIT.

    The equivalent register content can be accessed via bits [127:0] of

    the corresponding SVE Zn registers instead for vcpus that have SVE

    enabled (see below).

arm64 CCSIDR registers are demultiplexed by CSSELR value:

  0x6020 0000 0011 00 <csselr:8>

arm64 firmware pseudo-registers have the following bit pattern:

  0x6030 0000 0014 <regno:16>

arm64 SVE registers have the following bit patterns:

  0x6080 0000 0015 00 <n:5> <slice:5>   Zn bits[2048*slice + 2047 : 2048*slice]

  0x6050 0000 0015 04 <n:4> <slice:5>   Pn bits[256*slice + 255 : 256*slice]

  0x6050 0000 0015 060 <slice:5>        FFR bits[256*slice + 255 : 256*slice]

  0x6060 0000 0015 ffff                 KVM_REG_ARM64_SVE_VLS pseudo-register

Access to register IDs where 2048 * slice >= 128 * max_vq will fail with

ENOENT.  max_vq is the vcpu's maximum supported vector length in 128-bit

quadwords: see (**) below.

These registers are only accessible on vcpus for which SVE is enabled.

See KVM_ARM_VCPU_INIT for details.

In addition, except for KVM_REG_ARM64_SVE_VLS, these registers are not

accessible until the vcpu's SVE configuration has been finalized

using KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE).  See KVM_ARM_VCPU_INIT

and KVM_ARM_VCPU_FINALIZE for more information about this procedure.

KVM_REG_ARM64_SVE_VLS is a pseudo-register that allows the set of vector

lengths supported by the vcpu to be discovered and configured by

userspace.  When transferred to or from user memory via KVM_GET_ONE_REG

or KVM_SET_ONE_REG, the value of this register is of type

__u64[KVM_ARM64_SVE_VLS_WORDS], and encodes the set of vector lengths as

follows:

__u64 vector_lengths[KVM_ARM64_SVE_VLS_WORDS];

if (vq >= SVE_VQ_MIN && vq <= SVE_VQ_MAX &&

    ((vector_lengths[(vq - KVM_ARM64_SVE_VQ_MIN) / 64] >>

		((vq - KVM_ARM64_SVE_VQ_MIN) % 64)) & 1))

	/* Vector length vq * 16 bytes supported */

else

	/* Vector length vq * 16 bytes not supported */

(**) The maximum value vq for which the above condition is true is

max_vq.  This is the maximum vector length available to the guest on

this vcpu, and determines which register slices are visible through

this ioctl interface.

(See Documentation/arm64/sve.txt for an explanation of the "vq"

nomenclature.)

KVM_REG_ARM64_SVE_VLS is only accessible after KVM_ARM_VCPU_INIT.

KVM_ARM_VCPU_INIT initialises it to the best set of vector lengths that

the host supports.

Userspace may subsequently modify it if desired until the vcpu's SVE

configuration is finalized using KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE).

Apart from simply removing all vector lengths from the host set that

exceed some value, support for arbitrarily chosen sets of vector lengths

is hardware-dependent and may not be available.  Attempting to configure

an invalid set of vector lengths via KVM_SET_ONE_REG will fail with

EINVAL.

After the vcpu's SVE configuration is finalized, further attempts to

write this register will fail with EPERM.

MIPS registers are mapped using the lower 32 bits.  The upper 16 of that is

the register group type:

Type: vcpu ioctl

Parameters: struct kvm_one_reg (in and out)

Returns: 0 on success, negative value on failure

Errors include:

  ENOENT:   no such register

  EINVAL:   invalid register ID, or no such register

  EPERM:    (arm64) register access not allowed before vcpu finalization

(These error codes are indicative only: do not rely on a specific error

code being returned in a specific situation.)

This ioctl allows to receive the value of a single register implemented

in a vcpu. The register to read is indicated by the "id" field of the

	- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.

	  Depends on KVM_CAP_ARM_PMU_V3.

	- KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication

	  for arm64 only.

	  Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.

	  If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are

	  both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and

	  KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be

	  requested.

	- KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication

	  for arm64 only.

	  Depends on KVM_CAP_ARM_PTRAUTH_GENERIC.

	  If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are

	  both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and

	  KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be

	  requested.

	- KVM_ARM_VCPU_SVE: Enables SVE for the CPU (arm64 only).

	  Depends on KVM_CAP_ARM_SVE.

	  Requires KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):

	   * After KVM_ARM_VCPU_INIT:

	      - KVM_REG_ARM64_SVE_VLS may be read using KVM_GET_ONE_REG: the

	        initial value of this pseudo-register indicates the best set of

	        vector lengths possible for a vcpu on this host.

	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):

	      - KVM_RUN and KVM_GET_REG_LIST are not available;

	      - KVM_GET_ONE_REG and KVM_SET_ONE_REG cannot be used to access

	        the scalable archietctural SVE registers

	        KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() or

	        KVM_REG_ARM64_SVE_FFR;

	      - KVM_REG_ARM64_SVE_VLS may optionally be written using

	        KVM_SET_ONE_REG, to modify the set of vector lengths available

	        for the vcpu.

	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):

	      - the KVM_REG_ARM64_SVE_VLS pseudo-register is immutable, and can

	        no longer be written using KVM_SET_ONE_REG.

4.83 KVM_ARM_PREFERRED_TARGET

'index' and 'flags' fields in 'struct kvm_cpuid_entry2' are currently reserved,

userspace should not expect to get any particular value there.

4.119 KVM_ARM_VCPU_FINALIZE

Architectures: arm, arm64

Type: vcpu ioctl

Parameters: int feature (in)

Returns: 0 on success, -1 on error

Errors:

  EPERM:     feature not enabled, needs configuration, or already finalized

  EINVAL:    feature unknown or not present

Recognised values for feature:

  arm64      KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE)

Finalizes the configuration of the specified vcpu feature.

The vcpu must already have been initialised, enabling the affected feature, by

means of a successful KVM_ARM_VCPU_INIT call with the appropriate flag set in

features[].

For affected vcpu features, this is a mandatory step that must be performed

before the vcpu is fully usable.

Between KVM_ARM_VCPU_INIT and KVM_ARM_VCPU_FINALIZE, the feature may be

configured by use of ioctls such as KVM_SET_ONE_REG.  The exact configuration

that should be performaned and how to do it are feature-dependent.

Other calls that depend on a particular feature being finalized, such as

KVM_RUN, KVM_GET_REG_LIST, KVM_GET_ONE_REG and KVM_SET_ONE_REG, will fail with

-EPERM unless the feature has already been finalized by means of a

KVM_ARM_VCPU_FINALIZE call.

See KVM_ARM_VCPU_INIT for details of vcpu features that require finalization

using this ioctl.

5. The kvm_run structure

------------------------

	}

}

static inline void vcpu_ptrauth_setup_lazy(struct kvm_vcpu *vcpu) {}

#endif /* __ARM_KVM_EMULATE_H__ */

#ifndef __ARM_KVM_HOST_H__

#define __ARM_KVM_HOST_H__

#include <linux/errno.h>

#include <linux/types.h>

#include <linux/kvm_types.h>

#include <asm/cputype.h>

DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);

static inline int kvm_arm_init_sve(void) { return 0; }

u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);

int __attribute_const__ kvm_target_cpu(void);

int kvm_reset_vcpu(struct kvm_vcpu *vcpu);

	u32 cp15[NR_CP15_REGS];

};

typedef struct kvm_cpu_context kvm_cpu_context_t;

struct kvm_host_data {

	struct kvm_cpu_context host_ctxt;

};

typedef struct kvm_host_data kvm_host_data_t;

static inline void kvm_init_host_cpu_context(kvm_cpu_context_t *cpu_ctxt,

static inline void kvm_init_host_cpu_context(struct kvm_cpu_context *cpu_ctxt,

					     int cpu)

{

	/* The host's MPIDR is immutable, so let's set it up at boot time */

	struct kvm_vcpu_fault_info fault;

	/* Host FP context */

	kvm_cpu_context_t *host_cpu_context;

	struct kvm_cpu_context *host_cpu_context;

	/* VGIC state */

	struct vgic_cpu vgic_cpu;

static inline void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu) {}

static inline void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu) {}

static inline void kvm_vcpu_pmu_restore_guest(struct kvm_vcpu *vcpu) {}

static inline void kvm_vcpu_pmu_restore_host(struct kvm_vcpu *vcpu) {}

static inline void kvm_arm_vhe_guest_enter(void) {}

static inline void kvm_arm_vhe_guest_exit(void) {}

	return 0;

}

static inline int kvm_arm_vcpu_finalize(struct kvm_vcpu *vcpu, int feature)

{

	return -EINVAL;

}

static inline bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu)

{

	return true;

}

#endif /* __ARM_KVM_HOST_H__ */