[PULL 41/42] docs: rstfy confidential guest documentation

[Cédric Le Goater]

From: Cornelia Huck <cohuck@redhat.com>

Also rstfy the documentation for AMD SEV, and link it.

The documentation for PEF had been merged into the pseries doc,
fix the reference.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220204161251.241877-1-cohuck@redhat.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
 .../confidential-guest-support.rst}           |  15 +--
 .../i386/amd-memory-encryption.rst}           | 102 ++++++++++--------
 docs/system/index.rst                         |   1 +
 docs/system/ppc/pseries.rst                   |   2 +
 docs/system/target-i386.rst                   |   1 +
 MAINTAINERS                                   |   2 +-
 6 files changed, 67 insertions(+), 56 deletions(-)
 rename docs/{confidential-guest-support.txt => 
system/confidential-guest-support.rst} (77%)
 rename docs/{amd-memory-encryption.txt => 
system/i386/amd-memory-encryption.rst} (62%)

diff --git a/docs/confidential-guest-support.txt 
b/docs/system/confidential-guest-support.rst
similarity index 77%
rename from docs/confidential-guest-support.txt
rename to docs/system/confidential-guest-support.rst
index 71d07ba57af8..0c490dbda2b7 100644
--- a/docs/confidential-guest-support.txt
+++ b/docs/system/confidential-guest-support.rst
@@ -19,10 +19,10 @@ Running a Confidential Guest
 
 To run a confidential guest you need to add two command line parameters:
 
-1. Use "-object" to create a "confidential guest support" object.  The
+1. Use ``-object`` to create a "confidential guest support" object.  The
    type and parameters will vary with the specific mechanism to be
    used
-2. Set the "confidential-guest-support" machine parameter to the ID of
+2. Set the ``confidential-guest-support`` machine parameter to the ID of
    the object from (1).
 
 Example (for AMD SEV)::
@@ -37,13 +37,8 @@ Supported mechanisms
 
 Currently supported confidential guest mechanisms are:
 
-AMD Secure Encrypted Virtualization (SEV)
-    docs/amd-memory-encryption.txt
-
-POWER Protected Execution Facility (PEF)
-    docs/papr-pef.txt
-
-s390x Protected Virtualization (PV)
-    docs/system/s390x/protvirt.rst
+* AMD Secure Encrypted Virtualization (SEV) (see 
:doc:`i386/amd-memory-encryption`)
+* POWER Protected Execution Facility (PEF) (see 
:ref:`power-papr-protected-execution-facility-pef`)
+* s390x Protected Virtualization (PV) (see :doc:`s390x/protvirt`)
 
 Other mechanisms may be supported in future.
diff --git a/docs/amd-memory-encryption.txt 
b/docs/system/i386/amd-memory-encryption.rst
similarity index 62%
rename from docs/amd-memory-encryption.txt
rename to docs/system/i386/amd-memory-encryption.rst
index ffca382b5f5d..215946f813bb 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/system/i386/amd-memory-encryption.rst
@@ -1,3 +1,6 @@
+AMD Secure Encrypted Virtualization (SEV)
+=========================================
+
 Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
 
 SEV is an extension to the AMD-V architecture which supports running encrypted
@@ -24,17 +27,18 @@ the hypervisor to satisfy the requested function.
 
 Launching
 ---------
+
 Boot images (such as bios) must be encrypted before a guest can be booted. The
-MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images: LAUNCH_START,
-LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
+``MEMORY_ENCRYPT_OP`` ioctl provides commands to encrypt the images: 
``LAUNCH_START``,
+``LAUNCH_UPDATE_DATA``, ``LAUNCH_MEASURE`` and ``LAUNCH_FINISH``. These four 
commands
 together generate a fresh memory encryption key for the VM, encrypt the boot
 images and provide a measurement than can be used as an attestation of a
 successful launch.
 
-For a SEV-ES guest, the LAUNCH_UPDATE_VMSA command is also used to encrypt the
+For a SEV-ES guest, the ``LAUNCH_UPDATE_VMSA`` command is also used to encrypt 
the
 guest register state, or VM save area (VMSA), for all of the guest vCPUs.
 
-LAUNCH_START is called first to create a cryptographic launch context within
+``LAUNCH_START`` is called first to create a cryptographic launch context 
within
 the firmware. To create this context, guest owner must provide a guest policy,
 its public Diffie-Hellman key (PDH) and session parameters. These inputs
 should be treated as a binary blob and must be passed as-is to the SEV 
firmware.
@@ -45,37 +49,37 @@ in bad measurement). The guest policy is a 4-byte data 
structure containing
 several flags that restricts what can be done on a running SEV guest.
 See KM Spec section 3 and 6.2 for more details.
 
-The guest policy can be provided via the 'policy' property (see below)
+The guest policy can be provided via the ``policy`` property::
 
-# ${QEMU} \
-   sev-guest,id=sev0,policy=0x1...\
+  # ${QEMU} \
+     sev-guest,id=sev0,policy=0x1...\
 
 Setting the "SEV-ES required" policy bit (bit 2) will launch the guest as a
-SEV-ES guest (see below)
+SEV-ES guest::
 
-# ${QEMU} \
-   sev-guest,id=sev0,policy=0x5...\
+  # ${QEMU} \
+     sev-guest,id=sev0,policy=0x5...\
 
 The guest owner provided DH certificate and session parameters will be used to
 establish a cryptographic session with the guest owner to negotiate keys used
 for the attestation.
 
-The DH certificate and session blob can be provided via the 'dh-cert-file' and
-'session-file' properties (see below)
+The DH certificate and session blob can be provided via the ``dh-cert-file`` 
and
+``session-file`` properties::
 
-# ${QEMU} \
-     sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
+  # ${QEMU} \
+       sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
 
-LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
-created via the LAUNCH_START command. If required, this command can be called
+``LAUNCH_UPDATE_DATA`` encrypts the memory region using the cryptographic 
context
+created via the ``LAUNCH_START`` command. If required, this command can be 
called
 multiple times to encrypt different memory regions. The command also calculates
 the measurement of the memory contents as it encrypts.
 
-LAUNCH_UPDATE_VMSA encrypts all the vCPU VMSAs for a SEV-ES guest using the
-cryptographic context created via the LAUNCH_START command. The command also
+``LAUNCH_UPDATE_VMSA`` encrypts all the vCPU VMSAs for a SEV-ES guest using the
+cryptographic context created via the ``LAUNCH_START`` command. The command 
also
 calculates the measurement of the VMSAs as it encrypts them.
 
-LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory and,
+``LAUNCH_MEASURE`` can be used to retrieve the measurement of encrypted memory 
and,
 for a SEV-ES guest, encrypted VMSAs. This measurement is a signature of the
 memory contents and, for a SEV-ES guest, the VMSA contents, that can be sent
 to the guest owner as an attestation that the memory and VMSAs were encrypted
@@ -85,27 +89,28 @@ Since the guest owner knows the initial contents of the 
guest at boot, the
 attestation measurement can be verified by comparing it to what the guest owner
 expects.
 
-LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic
+``LAUNCH_FINISH`` finalizes the guest launch and destroys the cryptographic
 context.
 
-See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
+See SEV KM API Spec ([SEVKM]_) 'Launching a guest' usage flow (Appendix A) for 
the
 complete flow chart.
 
-To launch a SEV guest
+To launch a SEV guest::
 
-# ${QEMU} \
-    -machine ...,confidential-guest-support=sev0 \
-    -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
+  # ${QEMU} \
+      -machine ...,confidential-guest-support=sev0 \
+      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1
 
-To launch a SEV-ES guest
+To launch a SEV-ES guest::
 
-# ${QEMU} \
-    -machine ...,confidential-guest-support=sev0 \
-    -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5
+  # ${QEMU} \
+      -machine ...,confidential-guest-support=sev0 \
+      -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5
 
 An SEV-ES guest has some restrictions as compared to a SEV guest. Because the
 guest register state is encrypted and cannot be updated by the VMM/hypervisor,
 a SEV-ES guest:
+
  - Does not support SMM - SMM support requires updating the guest register
    state.
  - Does not support reboot - a system reset requires updating the guest 
register
@@ -114,35 +119,42 @@ a SEV-ES guest:
    manage booting APs.
 
 Debugging
------------
+---------
+
 Since the memory contents of a SEV guest are encrypted, hypervisor access to
 the guest memory will return cipher text. If the guest policy allows debugging,
 then a hypervisor can use the DEBUG_DECRYPT and DEBUG_ENCRYPT commands to 
access
 the guest memory region for debug purposes.  This is not supported in QEMU yet.
 
 Snapshot/Restore
------------------
+----------------
+
 TODO
 
 Live Migration
-----------------
+---------------
+
 TODO
 
 References
------------------
+----------
 
-AMD Memory Encryption whitepaper:
-https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
+`AMD Memory Encryption whitepaper
+<https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf>`_
 
-Secure Encrypted Virtualization Key Management:
-[1] 
http://developer.amd.com/wordpress/media/2017/11/55766_SEV-KM-API_Specification.pdf
+.. [SEVKM] `Secure Encrypted Virtualization Key Management
+   
<http://developer.amd.com/wordpress/media/2017/11/55766_SEV-KM-API_Specification.pdf>`_
 
 KVM Forum slides:
-http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
-https://www.linux-kvm.org/images/9/94/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf
-
-AMD64 Architecture Programmer's Manual:
-   http://support.amd.com/TechDocs/24593.pdf
-   SME is section 7.10
-   SEV is section 15.34
-   SEV-ES is section 15.35
+
+* `AMD’s Virtualization Memory Encryption (2016)
+  
<http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf>`_
+* `Extending Secure Encrypted Virtualization With SEV-ES (2018)
+  
<https://www.linux-kvm.org/images/9/94/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf>`_
+
+`AMD64 Architecture Programmer's Manual:
+<http://support.amd.com/TechDocs/24593.pdf>`_
+
+* SME is section 7.10
+* SEV is section 15.34
+* SEV-ES is section 15.35
diff --git a/docs/system/index.rst b/docs/system/index.rst
index 73bbedbc22d4..23e30e26e5e6 100644
--- a/docs/system/index.rst
+++ b/docs/system/index.rst
@@ -34,3 +34,4 @@ or Hypervisor.Framework.
    targets
    security
    multi-process
+   confidential-guest-support
diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst
index 569237dc0c8b..d9b65ad4e850 100644
--- a/docs/system/ppc/pseries.rst
+++ b/docs/system/ppc/pseries.rst
@@ -224,6 +224,8 @@ nested. Combinations not shown in the table are not 
available.
 .. [3] Introduced on Power10 machines.
 
 
+.. _power-papr-protected-execution-facility-pef:
+
 POWER (PAPR) Protected Execution Facility (PEF)
 -----------------------------------------------
 
diff --git a/docs/system/target-i386.rst b/docs/system/target-i386.rst
index 4daa53c35d8f..96bf54889a82 100644
--- a/docs/system/target-i386.rst
+++ b/docs/system/target-i386.rst
@@ -28,6 +28,7 @@ Architectural features
    i386/cpu
    i386/kvm-pv
    i386/sgx
+   i386/amd-memory-encryption
 
 .. _pcsys_005freq:
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 9814580975c5..8944fb561c0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -408,7 +408,7 @@ M: Paolo Bonzini <pbonzini@redhat.com>
 M: Marcelo Tosatti <mtosatti@redhat.com>
 L: kvm@vger.kernel.org
 S: Supported
-F: docs/amd-memory-encryption.txt
+F: docs/system/i386/amd-memory-encryption.rst
 F: docs/system/i386/sgx.rst
 F: target/i386/kvm/
 F: target/i386/sev*
-- 
2.34.1