xb_0916

KVM系统调用说明

1. General description

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

The kvm API is a set of ioctls that are issued to control various aspects

of a virtual machine. The ioctls belong to three classes

- System ioctls: These query and set global attributes which affect the

whole kvm subsystem. In addition a system ioctl is used to create

virtual machines

- VM ioctls: These query and set attributes that affect an entire virtual

machine, for example memory layout. In addition a VM ioctl is used to

create virtual cpus (vcpus).

Only run VM ioctls from the same process (address space) that was used

to create the VM.

- vcpu ioctls: These query and set attributes that control the operation

of a single virtual cpu.

Only run vcpu ioctls from the same thread that was used to create the

vcpu.

2. File descriptors

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

The kvm API is centered around file descriptors. An initial

open("/dev/kvm") obtains a handle to the kvm subsystem; this handle

can be used to issue system ioctls. A KVM_CREATE_VM ioctl on this

handle will create a VM file descriptor which can be used to issue VM

ioctls. A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu

and return a file descriptor pointing to it. Finally, ioctls on a vcpu

fd can be used to control the vcpu, including the important task of

actually running guest code.

In general file descriptors can be migrated among processes by means

of fork() and the SCM_RIGHTS facility of unix domain socket. These

kinds of tricks are explicitly not supported by kvm. While they will

not cause harm to the host, their actual behavior is not guaranteed by

the API. The only supported use is one virtual machine per process,

and one vcpu per thread.

3. Extensions

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

As of Linux 2.6.22, the KVM ABI has been stabilized: no backward

incompatible change are allowed. However, there is an extension

facility that allows backward-compatible extensions to the API to be

queried and used.

The extension mechanism is not based on on the Linux version number.

Instead, kvm defines extension identifiers and a facility to query

[NextPage][/NextPage]

whether a particular extension identifier is available. If it is, a

set of ioctls is available for application use.

4. API description

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

This section describes ioctls that can be used to control kvm guests.

For each ioctl, the following information is provided along with a

description:

Capability: which KVM extension provides this ioctl. Can be 'basic',

which means that is will be provided by any kernel that supports

API version 12 (see section 4.1), or a KVM_CAP_xyz constant, which

means availability needs to be checked with KVM_CHECK_EXTENSION

(see section 4.4).

Architectures: which instruction set architectures provide this ioctl.

x86 includes both i386 and x86_64.

Type: system, vm, or vcpu.

Parameters: what parameters are accepted by the ioctl.

Returns: the return value. General error numbers (EBADF, ENOMEM, EINVAL)

are not detailed, but errors with specific meanings are.

4.1 KVM_GET_API_VERSION

Capability: basic

Architectures: all

Type: system ioctl

Parameters: none

Returns: the constant KVM_API_VERSION (=12)

This identifies the API version as the stable kvm API. It is not

expected that this number will change. However, Linux 2.6.20 and

2.6.21 report earlier versions; these are not documented and not

supported. Applications should refuse to run if KVM_GET_API_VERSION

returns a value other than 12. If this check passes, all ioctls

described as 'basic' will be available.

4.2 KVM_CREATE_VM

Capability: basic

Architectures: all

Type: system ioctl

Parameters: machine type identifier (KVM_VM_*)

Returns: a VM fd that can be used to control the new virtual machine.

The new VM has no virtual cpus and no memory. An mmap() of a VM fd

will access the virtual machine's physical address space; offset zero

corresponds to guest physical address zero. Use of mmap() on a VM fd

is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is

available.

You most certainly want to use 0 as machine type.

In order to create user controlled virtual machines on S390, check

KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as

privileged user (CAP_SYS_ADMIN).

4.3 KVM_GET_MSR_INDEX_LIST

Capability: basic

Architectures: x86

Type: system

Parameters: struct kvm_msr_list (in/out)

Returns: 0 on success; -1 on e

[NextPage][/NextPage]

rror

Errors:

E2BIG: the msr index list is to be to fit in the array specified by

the user.

struct kvm_msr_list {

__u32 nmsrs; /* number of msrs in entries */

__u32 indices[0];

};

This ioctl returns the guest msrs that are supported. The list varies

by kvm version and host processor, but does not change otherwise. The

user fills in the size of the indices array in nmsrs, and in return

kvm adjusts nmsrs to reflect the actual number of msrs and fills in

the indices array with their numbers.

Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are

not returned in the MSR list, as different vcpus can have a different number

of banks, as set via the KVM_X86_SETUP_MCE ioctl.

4.4 KVM_CHECK_EXTENSION

Capability: basic

Architectures: all

Type: system ioctl

Parameters: extension identifier (KVM_CAP_*)

Returns: 0 if unsupported; 1 (or some other positive integer) if supported

The API allows the application to query about extensions to the core

kvm API. Userspace passes an extension identifier (an integer) and

receives an integer that describes the extension availability.

Generally 0 means no and 1 means yes, but some extensions may report

additional information in the integer return value.

4.5 KVM_GET_VCPU_MMAP_SIZE

Capability: basic

Architectures: all

Type: system ioctl

Parameters: none

Returns: size of vcpu mmap area, in bytes

The KVM_RUN ioctl (cf.) communicates with userspace via a shared

memory region. This ioctl returns the size of that region. See the

KVM_RUN documentation for details.

4.6 KVM_SET_MEMORY_REGION

Capability: basic

Architectures: all

Type: vm ioctl

Parameters: struct kvm_memory_region (in)

Returns: 0 on success, -1 on error

This ioctl is obsolete and has been removed.

4.7 KVM_CREATE_VCPU

Capability: basic

Architectures: all

Type: vm ioctl

Parameters: vcpu id (apic id on x86)

Returns: vcpu fd on success, -1 on error

This API adds a vcpu to a virtual machine. The vcpu id is a small integer

in the range [0, max_vcpus).

The recommended max_vcpus value can be retrieved using the KVM_CAP_NR_VCPUS of

the KVM_CHECK_EXTENSION ioctl() at run-time.

The maximum possible value for max_vcpus can be retrieved using the

KVM_CAP_MAX_VCPUS of the KVM_CHECK_EXTENSION ioctl() at run-time.

If the KVM_CAP_NR_VCPUS does not exist

[NextPage][/NextPage]

, you should assume that max_vcpus is 4

cpus max.

If the KVM_CAP_MAX_VCPUS does not exist, you should assume that max_vcpus is

same as the value returned from KVM_CAP_NR_VCPUS.

On powerpc using book3s_hv mode, the vcpus are mapped onto virtual

threads in one or more virtual CPU cores. (This is because the

hardware requires all the hardware threads in a CPU core to be in the

same partition.) The KVM_CAP_PPC_SMT capability indicates the number

of vcpus per virtual core (vcore). The vcore id is obtained by

dividing the vcpu id by the number of vcpus per vcore. The vcpus in a

given vcore will always be in the same physical core as each other

(though that might be a different physical core from time to time).

Userspace can control the threading (SMT) mode of the guest by its

allocation of vcpu ids. For example, if userspace wants

single-threaded guest vcpus, it should make all vcpu ids be a multiple

of the number of vcpus per vcore.