Re: [PATCH] docs: rstfy confidential guest documentation

[Daniel Henrique Barboza <danielhb413@gmail.com>]

On 2/4/22 13:12, Cornelia Huck wrote:
> Also rstfy the documentation for AMD SEV, and link it.
> 
> The documentation for PEF had been merged into the pseries doc,
> fix the reference.

Yeah, we forgot to fix/remove the existing papr-pef.txt reference after the changes we
made. Thanks for fixing this up and making a new ref for it in the pseries doc.

> 
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> ---
>   MAINTAINERS                                   |   2 +-
>   .../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 +
>   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/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*
> 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)

I approve the "(see below)" instances that you ended up removing. It sounded a bit redundant
when used in the end of the sentence.


Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>


> +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:
>