Merge tag 'kvmarm-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

   - MDCR_EL3.TPM (bit 6) must be initialized to 0b0

  For CPUs with support for 64-byte loads and stores without status (FEAT_LS64):

  - If the kernel is entered at EL1 and EL2 is present:

    - HCRX_EL2.EnALS (bit 1) must be initialised to 0b1.

  For CPUs with support for 64-byte stores with status (FEAT_LS64_V):

  - If the kernel is entered at EL1 and EL2 is present:

    - HCRX_EL2.EnASR (bit 2) must be initialised to 0b1.

The requirements described above for CPU mode, caches, MMUs, architected

timers, coherency and system registers apply to all CPUs.  All CPUs must

enter the kernel in the same exception level.  Where the values documented

HWCAP3_LSFE

    Functionality implied by ID_AA64ISAR3_EL1.LSFE == 0b0001

HWCAP3_LS64

    Functionality implied by ID_AA64ISAR1_EL1.LS64 == 0b0001. Note that

    the function of instruction ld64b/st64b requires support by CPU, system

    and target (device) memory location and HWCAP3_LS64 implies the support

    of CPU. User should only use ld64b/st64b on supported target (device)

    memory location, otherwise fallback to the non-atomic alternatives.

4. Unused AT_HWCAP bits

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

information or because there is no device mapped at the accessed IPA, then

userspace can ask the kernel to inject an external abort using the address

from the exiting fault on the VCPU. It is a programming error to set

ext_dabt_pending after an exit which was not either KVM_EXIT_MMIO or

KVM_EXIT_ARM_NISV. This feature is only available if the system supports

KVM_CAP_ARM_INJECT_EXT_DABT. This is a helper which provides commonality in

how userspace reports accesses for the above cases to guests, across different

userspace implementations. Nevertheless, userspace can still emulate all Arm

exceptions by manipulating individual registers using the KVM_SET_ONE_REG API.

ext_dabt_pending after an exit which was not either KVM_EXIT_MMIO,

KVM_EXIT_ARM_NISV, or KVM_EXIT_ARM_LDST64B. This feature is only available if

the system supports KVM_CAP_ARM_INJECT_EXT_DABT. This is a helper which

provides commonality in how userspace reports accesses for the above cases to

guests, across different userspace implementations. Nevertheless, userspace

can still emulate all Arm exceptions by manipulating individual registers

using the KVM_SET_ONE_REG API.

See KVM_GET_VCPU_EVENTS for the data structure.

::

		/* KVM_EXIT_ARM_NISV */

		/* KVM_EXIT_ARM_NISV / KVM_EXIT_ARM_LDST64B */

		struct {

			__u64 esr_iss;

			__u64 fault_ipa;

		} arm_nisv;

- KVM_EXIT_ARM_NISV:

Used on arm64 systems. If a guest accesses memory not in a memslot,

KVM will typically return to userspace and ask it to do MMIO emulation on its

behalf. However, for certain classes of instructions, no instruction decode

queried outside of a protected VM context, the feature will not be

exposed if queried on a protected VM file descriptor.

- KVM_EXIT_ARM_LDST64B:

Used on arm64 systems. When a guest using a LD64B, ST64B, ST64BV, ST64BV0,

outside of a memslot, KVM will return to userspace with KVM_EXIT_ARM_LDST64B,

exposing the relevant ESR_EL2 information and faulting IPA, similarly to

KVM_EXIT_ARM_NISV.

Userspace is supposed to fully emulate the instructions, which includes:

	- fetch of the operands for a store, including ACCDATA_EL1 in the case

	  of a ST64BV0 instruction

	- deal with the endianness if the guest is big-endian

	- emulate the access, including the delivery of an exception if the

	  access didn't succeed

	- provide a return value in the case of ST64BV/ST64BV0

	- return the data in the case of a load

	- increment PC if the instruction was successfully executed

Note that there is no expectation of performance for this emulation, as it

involves a large number of interaction with the guest state. It is, however,

expected that the instruction's semantics are preserved, specially the

single-copy atomicity property of the 64 byte access.

This exit reason must be handled if userspace sets ID_AA64ISAR1_EL1.LS64 to a

non-zero value, indicating that FEAT_LS64* is enabled.

::

		/* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */

config ARM64_SW_TTBR0_PAN

	bool "Emulate Privileged Access Never using TTBR0_EL1 switching"

	depends on !KCSAN

	select ARM64_PAN

	help

	  Enabling this option prevents the kernel from accessing

	  user-space memory directly by pointing TTBR0_EL1 to a reserved

	  to work on pre-ARMv8.1 hardware and the performance impact is

	  minimal. If unsure, say Y.

config ARM64_PAN

	bool "Enable support for Privileged Access Never (PAN)"

	default y

	help

	  Privileged Access Never (PAN; part of the ARMv8.1 Extensions)

	  prevents the kernel or hypervisor from accessing user-space (EL0)

	  memory directly.

	  Choosing this option will cause any unprotected (not using

	  copy_to_user et al) memory access to fail with a permission fault.

	  The feature is detected at runtime, and will remain as a 'nop'

	  instruction if the cpu does not implement the feature.

config ARM64_LSE_ATOMICS

	bool

	default ARM64_USE_LSE_ATOMICS

config ARM64_USE_LSE_ATOMICS

	bool "Atomic instructions"

	default y

	help

	  As part of the Large System Extensions, ARMv8.1 introduces new

	  atomic instructions that are designed specifically to scale in

	  very large systems.

	  Say Y here to make use of these instructions for the in-kernel

	  atomic routines. This incurs a small overhead on CPUs that do

	  not support these instructions.

endmenu # "ARMv8.1 architectural features"

menu "ARMv8.2 architectural features"

	depends on ARM64_AS_HAS_MTE && ARM64_TAGGED_ADDR_ABI

	depends on AS_HAS_ARMV8_5

	# Required for tag checking in the uaccess routines

	select ARM64_PAN

	select ARCH_HAS_SUBPAGE_FAULTS

	select ARCH_USES_HIGH_VMA_FLAGS

	select ARCH_USES_PG_ARCH_2

config ARM64_EPAN

	bool "Enable support for Enhanced Privileged Access Never (EPAN)"

	default y

	depends on ARM64_PAN

	help

	  Enhanced Privileged Access Never (EPAN) allows Privileged

	  Access Never to be used with Execute-only mappings.

			   "cap must be < ARM64_NCAPS");

	switch (cap) {

	case ARM64_HAS_PAN:

		return IS_ENABLED(CONFIG_ARM64_PAN);

	case ARM64_HAS_EPAN:

		return IS_ENABLED(CONFIG_ARM64_EPAN);

	case ARM64_SVE: