Merge tag 'kvm-s390-next-5.19-2' of...

	__u32 reserved[3];

  };

cmd values:

**Ultravisor return codes**

The Ultravisor return (reason) codes are provided by the kernel if a

Ultravisor call has been executed to achieve the results expected by

the command. Therefore they are independent of the IOCTL return

code. If KVM changes `rc`, its value will always be greater than 0

hence setting it to 0 before issuing a PV command is advised to be

able to detect a change of `rc`.

**cmd values:**

KVM_PV_ENABLE

  Allocate memory and register the VM with the Ultravisor, thereby

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

KVM_PV_DISABLE

  Deregister the VM from the Ultravisor and reclaim the memory that

  had been donated to the Ultravisor, making it usable by the kernel

  again.  All registered VCPUs are converted back to non-protected

  Verify the integrity of the unpacked image. Only if this succeeds,

  KVM is allowed to start protected VCPUs.

KVM_PV_INFO

  :Capability: KVM_CAP_S390_PROTECTED_DUMP

  Presents an API that provides Ultravisor related data to userspace

  via subcommands. len_max is the size of the user space buffer,

  len_written is KVM's indication of how much bytes of that buffer

  were actually written to. len_written can be used to determine the

  valid fields if more response fields are added in the future.

  ::

     enum pv_cmd_info_id {

	KVM_PV_INFO_VM,

	KVM_PV_INFO_DUMP,

     };

     struct kvm_s390_pv_info_header {

	__u32 id;

	__u32 len_max;

	__u32 len_written;

	__u32 reserved;

     };

     struct kvm_s390_pv_info {

	struct kvm_s390_pv_info_header header;

	struct kvm_s390_pv_info_dump dump;

	struct kvm_s390_pv_info_vm vm;

     };

**subcommands:**

  KVM_PV_INFO_VM

    This subcommand provides basic Ultravisor information for PV

    hosts. These values are likely also exported as files in the sysfs

    firmware UV query interface but they are more easily available to

    programs in this API.

    The installed calls and feature_indication members provide the

    installed UV calls and the UV's other feature indications.

    The max_* members provide information about the maximum number of PV

    vcpus, PV guests and PV guest memory size.

    ::

      struct kvm_s390_pv_info_vm {

	__u64 inst_calls_list[4];

	__u64 max_cpus;

	__u64 max_guests;

	__u64 max_guest_addr;

	__u64 feature_indication;

      };

  KVM_PV_INFO_DUMP

    This subcommand provides information related to dumping PV guests.

    ::

      struct kvm_s390_pv_info_dump {

	__u64 dump_cpu_buffer_len;

	__u64 dump_config_mem_buffer_per_1m;

	__u64 dump_config_finalize_len;

      };

KVM_PV_DUMP

  :Capability: KVM_CAP_S390_PROTECTED_DUMP

  Presents an API that provides calls which facilitate dumping a

  protected VM.

  ::

    struct kvm_s390_pv_dmp {

      __u64 subcmd;

      __u64 buff_addr;

      __u64 buff_len;

      __u64 gaddr;		/* For dump storage state */

    };

  **subcommands:**

  KVM_PV_DUMP_INIT

    Initializes the dump process of a protected VM. If this call does

    not succeed all other subcommands will fail with -EINVAL. This

    subcommand will return -EINVAL if a dump process has not yet been

    completed.

    Not all PV vms can be dumped, the owner needs to set `dump

    allowed` PCF bit 34 in the SE header to allow dumping.

  KVM_PV_DUMP_CONFIG_STOR_STATE

     Stores `buff_len` bytes of tweak component values starting with

     the 1MB block specified by the absolute guest address

     (`gaddr`). `buff_len` needs to be `conf_dump_storage_state_len`

     aligned and at least >= the `conf_dump_storage_state_len` value

     provided by the dump uv_info data. buff_user might be written to

     even if an error rc is returned. For instance if we encounter a

     fault after writing the first page of data.

  KVM_PV_DUMP_COMPLETE

    If the subcommand succeeds it completes the dump process and lets

    KVM_PV_DUMP_INIT be called again.

    On success `conf_dump_finalize_len` bytes of completion data will be

    stored to the `buff_addr`. The completion data contains a key

    derivation seed, IV, tweak nonce and encryption keys as well as an

    authentication tag all of which are needed to decrypt the dump at a

    later time.

4.126 KVM_X86_SET_MSR_FILTER

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

This ioctl injects an event channel interrupt directly to the guest vCPU.

4.136 KVM_S390_PV_CPU_COMMAND

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

:Capability: KVM_CAP_S390_PROTECTED_DUMP

:Architectures: s390

:Type: vcpu ioctl

:Parameters: none

:Returns: 0 on success, < 0 on error

This ioctl closely mirrors `KVM_S390_PV_COMMAND` but handles requests

for vcpus. It re-uses the kvm_s390_pv_dmp struct and hence also shares

the command ids.

**command:**

KVM_PV_DUMP

  Presents an API that provides calls which facilitate dumping a vcpu

  of a protected VM.

**subcommand:**

KVM_PV_DUMP_CPU

  Provides encrypted dump data like register values.

  The length of the returned data is provided by uv_info.guest_cpu_stor_len.

5. The kvm_run structure

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

When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of

type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request.

8.37 KVM_CAP_S390_PROTECTED_DUMP

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

:Capability: KVM_CAP_S390_PROTECTED_DUMP

:Architectures: s390

:Type: vm

This capability indicates that KVM and the Ultravisor support dumping

PV guests. The `KVM_PV_DUMP` command is available for the

`KVM_S390_PV_COMMAND` ioctl and the `KVM_PV_INFO` command provides

dump related UV data. Also the vcpu ioctl `KVM_S390_PV_CPU_COMMAND` is

available and supports the `KVM_PV_DUMP_CPU` subcommand.

9. Known KVM API problems

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

   s390-diag

   s390-pv

   s390-pv-boot

   s390-pv-dump

.. SPDX-License-Identifier: GPL-2.0

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

s390 (IBM Z) Protected Virtualization dumps

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

Summary

-------

Dumping a VM is an essential tool for debugging problems inside

it. This is especially true when a protected VM runs into trouble as

there's no way to access its memory and registers from the outside

while it's running.

However when dumping a protected VM we need to maintain its

confidentiality until the dump is in the hands of the VM owner who

should be the only one capable of analysing it.

The confidentiality of the VM dump is ensured by the Ultravisor who

provides an interface to KVM over which encrypted CPU and memory data

can be requested. The encryption is based on the Customer

Communication Key which is the key that's used to encrypt VM data in a

way that the customer is able to decrypt.

Dump process

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

A dump is done in 3 steps:

**Initiation**

This step initializes the dump process, generates cryptographic seeds

and extracts dump keys with which the VM dump data will be encrypted.

**Data gathering**

Currently there are two types of data that can be gathered from a VM:

the memory and the vcpu state.

The vcpu state contains all the important registers, general, floating

point, vector, control and tod/timers of a vcpu. The vcpu dump can

contain incomplete data if a vcpu is dumped while an instruction is

emulated with help of the hypervisor. This is indicated by a flag bit

in the dump data. For the same reason it is very important to not only

write out the encrypted vcpu state, but also the unencrypted state

from the hypervisor.

The memory state is further divided into the encrypted memory and its

metadata comprised of the encryption tweaks and status flags. The

encrypted memory can simply be read once it has been exported. The

time of the export does not matter as no re-encryption is

needed. Memory that has been swapped out and hence was exported can be

read from the swap and written to the dump target without need for any

special actions.

The tweaks / status flags for the exported pages need to be requested

from the Ultravisor.

**Finalization**

The finalization step will provide the data needed to be able to

decrypt the vcpu and memory data and end the dump process. When this

step completes successfully a new dump initiation can be started.

		uv_info.max_num_sec_conf = uvcb.max_num_sec_conf;

		uv_info.max_guest_cpu_id = uvcb.max_guest_cpu_id;

		uv_info.uv_feature_indications = uvcb.uv_feature_indications;

		uv_info.supp_se_hdr_ver = uvcb.supp_se_hdr_versions;

		uv_info.supp_se_hdr_pcf = uvcb.supp_se_hdr_pcf;

		uv_info.conf_dump_storage_state_len = uvcb.conf_dump_storage_state_len;

		uv_info.conf_dump_finalize_len = uvcb.conf_dump_finalize_len;

	}

#ifdef CONFIG_PROTECTED_VIRTUALIZATION_GUEST

	u64 guest_len;

	unsigned long stor_base;

	void *stor_var;

	bool dumping;

};

struct kvm_arch{