diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/migration.rst | 9 | ||||
| -rw-r--r-- | docs/specs/ivshmem-spec.txt | 8 | ||||
| -rw-r--r-- | docs/specs/tpm.txt | 104 |
3 files changed, 117 insertions, 4 deletions
diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst index e7658ab050..220059679a 100644 --- a/docs/devel/migration.rst +++ b/docs/devel/migration.rst @@ -419,8 +419,13 @@ The functions to do that are inside a vmstate definition, and are called: This function is called before we save the state of one device. -Example: You can look at hpet.c, that uses the three function to -massage the state that is transferred. +- ``int (*post_save)(void *opaque);`` + + This function is called after we save the state of one device + (even upon failure, unless the call to pre_save returned an error). + +Example: You can look at hpet.c, that uses the first three functions +to massage the state that is transferred. The ``VMSTATE_WITH_TMP`` macro may be useful when the migration data doesn't match the stored device data well; it allows an diff --git a/docs/specs/ivshmem-spec.txt b/docs/specs/ivshmem-spec.txt index a1f5499796..042f7eae22 100644 --- a/docs/specs/ivshmem-spec.txt +++ b/docs/specs/ivshmem-spec.txt @@ -17,12 +17,16 @@ get interrupted by its peers. There are two basic configurations: -- Just shared memory: -device ivshmem-plain,memdev=HMB,... +- Just shared memory: + + -device ivshmem-plain,memdev=HMB,... This uses host memory backend HMB. It should have option "share" set. -- Shared memory plus interrupts: -device ivshmem,chardev=CHR,vectors=N,... +- Shared memory plus interrupts: + + -device ivshmem-doorbell,chardev=CHR,vectors=N,... An ivshmem server must already be running on the host. The device connects to the server's UNIX domain socket via character device diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt index 1af82bba86..5d8c26b1ad 100644 --- a/docs/specs/tpm.txt +++ b/docs/specs/tpm.txt @@ -34,6 +34,25 @@ The CRB interface makes a memory mapped IO region in the area 0xfed40000 - QEMU files related to TPM CRB interface: - hw/tpm/tpm_crb.c += fw_cfg interface = + +The bios/firmware may read the "etc/tpm/config" fw_cfg entry for +configuring the guest appropriately. + +The entry of 6 bytes has the following content, in little-endian: + + #define TPM_VERSION_UNSPEC 0 + #define TPM_VERSION_1_2 1 + #define TPM_VERSION_2_0 2 + + #define TPM_PPI_VERSION_NONE 0 + #define TPM_PPI_VERSION_1_30 1 + + struct FwCfgTPMConfig { + uint32_t tpmppi_address; /* PPI memory location */ + uint8_t tpm_version; /* TPM version */ + uint8_t tpmppi_version; /* PPI version */ + }; = ACPI Interface = @@ -57,6 +76,91 @@ URL: https://trustedcomputinggroup.org/tcg-acpi-specification/ +== ACPI PPI Interface == + +QEMU supports the Physical Presence Interface (PPI) for TPM 1.2 and TPM 2. This +interface requires ACPI and firmware support. The specification can be found at +the following URL: + +https://trustedcomputinggroup.org/resource/tcg-physical-presence-interface-specification/ + +PPI enables a system administrator (root) to request a modification to the +TPM upon reboot. The PPI specification defines the operation requests and the +actions the firmware has to take. The system administrator passes the operation +request number to the firmware through an ACPI interface which writes this +number to a memory location that the firmware knows. Upon reboot, the firmware +finds the number and sends commands to the the TPM. The firmware writes the TPM +result code and the operation request number to a memory location that ACPI can +read from and pass the result on to the administrator. + +The PPI specification defines a set of mandatory and optional operations for +the firmware to implement. The ACPI interface also allows an administrator to +list the supported operations. In QEMU the ACPI code is generated by QEMU, yet +the firmware needs to implement support on a per-operations basis, and +different firmwares may support a different subset. Therefore, QEMU introduces +the virtual memory device for PPI where the firmware can indicate which +operations it supports and ACPI can enable the ones that are supported and +disable all others. This interface lies in main memory and has the following +layout: + + +----------+--------+--------+-------------------------------------------+ + | Field | Length | Offset | Description | + +----------+--------+--------+-------------------------------------------+ + | func | 0x100 | 0x000 | Firmware sets values for each supported | + | | | | operation. See defined values below. | + +----------+--------+--------+-------------------------------------------+ + | ppin | 0x1 | 0x100 | SMI interrupt to use. Set by firmware. | + | | | | Not supported. | + +----------+--------+--------+-------------------------------------------+ + | ppip | 0x4 | 0x101 | ACPI function index to pass to SMM code. | + | | | | Set by ACPI. Not supported. | + +----------+--------+--------+-------------------------------------------+ + | pprp | 0x4 | 0x105 | Result of last executed operation. Set by | + | | | | firmware. See function index 5 for values.| + +----------+--------+--------+-------------------------------------------+ + | pprq | 0x4 | 0x109 | Operation request number to execute. See | + | | | | 'Physical Presence Interface Operation | + | | | | Summary' tables in specs. Set by ACPI. | + +----------+--------+--------+-------------------------------------------+ + | pprm | 0x4 | 0x10d | Operation request optional parameter. | + | | | | Values depend on operation. Set by ACPI. | + +----------+--------+--------+-------------------------------------------+ + | lppr | 0x4 | 0x111 | Last executed operation request number. | + | | | | Copied from pprq field by firmware. | + +----------+--------+--------+-------------------------------------------+ + | fret | 0x4 | 0x115 | Result code from SMM function. | + | | | | Not supported. | + +----------+--------+--------+-------------------------------------------+ + | res1 | 0x40 | 0x119 | Reserved for future use | + +----------+--------+--------+-------------------------------------------+ + | next_step| 0x1 | 0x159 | Operation to execute after reboot by | + | | | | firmware. Used by firmware. | + +----------+--------+--------+-------------------------------------------+ + | movv | 0x1 | 0x15a | Memory overwrite variable | + +----------+--------+--------+-------------------------------------------+ + + The following values are supported for the 'func' field. They correspond + to the values used by ACPI function index 8. + + +----------+-------------------------------------------------------------+ + | value | Description | + +----------+-------------------------------------------------------------+ + | 0 | Operation is not implemented. | + +----------+-------------------------------------------------------------+ + | 1 | Operation is only accessible through firmware. | + +----------+-------------------------------------------------------------+ + | 2 | Operation is blocked for OS by firmware configuration. | + +----------+-------------------------------------------------------------+ + | 3 | Operation is allowed and physically present user required. | + +----------+-------------------------------------------------------------+ + | 4 | Operation is allowed and physically present user is not | + | | required. | + +----------+-------------------------------------------------------------+ + +The location of the table is given by the fw_cfg tpmppi_address field. +The PPI memory region size is 0x400 (TPM_PPI_ADDR_SIZE) to leave +enough room for future updates. + QEMU files related to TPM ACPI tables: - hw/i386/acpi-build.c |