All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Connor Kuehl <ckuehl@redhat.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Jiri Slaby <jslaby@suse.cz>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
	Aurelien Jarno <aurelien@aurel32.net>,
	David Gibson <david@gibson.dropbear.id.au>,
	David Hildenbrand <david@redhat.com>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Richard Henderson <richard.henderson@linaro.org>
Subject: Re: [PATCH v6 0/6] Qemu SEV-ES guest support
Date: Fri, 5 Feb 2021 11:59:40 +0100	[thread overview]
Message-ID: <9cfe8d87-c440-6ce8-7b1c-beb46e17c173@redhat.com> (raw)
In-Reply-To: <cover.1611682609.git.thomas.lendacky@amd.com>

On 26/01/21 18:36, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
> 
> This patch series provides support for launching an SEV-ES guest.
> 
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
> 
> In order to allow a hypervisor to perform functions on behalf of a guest,
> there is architectural support for notifying a guest's operating system
> when certain types of VMEXITs are about to occur. This allows the guest to
> selectively share information with the hypervisor to satisfy the requested
> function. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
> 
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
> 
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
> 
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
> 
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
> 
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
>      https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
> 
> Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
> Cc: Aurelien Jarno <aurelien@aurel32.net>
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> 
> ---
> 
> These patches are based on commit:
> 9cd69f1a27 ("Merge remote-tracking branch 'remotes/stefanberger/tags/pull-tpm-2021-01-25-1' into staging")
> 
> Additionally, these patches pre-req the following patch series that has
> not yet been accepted into the Qemu tree:
> 
> [PATCH v2 0/2] sev: enable secret injection to a self described area in OVMF
>    https://lore.kernel.org/qemu-devel/20201214154429.11023-1-jejb@linux.ibm.com/
> 
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v14
> 
> Changes since v5:
> - Rework the reset prevention patch to not issue the error message if the
>    --no-reboot option has been specified for SEV-ES guests.
> 
> Changes since v4:
> - Add support for an updated Firmware GUID table implementation, that
>    is now present in OVMF SEV-ES firmware, when searching for the reset
>    vector information. The code will check for the new implementation
>    first, followed by the original implementation to maintain backward
>    compatibility.
> 
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
>    at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
> 
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
> 
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
> 
> Tom Lendacky (6):
>    sev/i386: Add initial support for SEV-ES
>    sev/i386: Require in-kernel irqchip support for SEV-ES guests
>    sev/i386: Allow AP booting under SEV-ES
>    sev/i386: Don't allow a system reset under an SEV-ES guest
>    kvm/i386: Use a per-VM check for SMM capability
>    sev/i386: Enable an SEV-ES guest based on SEV policy
> 
>   accel/kvm/kvm-all.c       |  69 +++++++++++++++++++++
>   accel/stubs/kvm-stub.c    |   5 ++
>   hw/i386/pc_sysfw.c        |  10 ++-
>   include/sysemu/cpus.h     |   2 +
>   include/sysemu/hw_accel.h |   5 ++
>   include/sysemu/kvm.h      |  26 ++++++++
>   include/sysemu/sev.h      |   3 +
>   softmmu/cpus.c            |   5 ++
>   softmmu/runstate.c        |   3 +
>   target/arm/kvm.c          |   5 ++
>   target/i386/cpu.c         |   1 +
>   target/i386/kvm/kvm.c     |  10 ++-
>   target/i386/sev-stub.c    |   6 ++
>   target/i386/sev.c         | 124 +++++++++++++++++++++++++++++++++++++-
>   target/i386/sev_i386.h    |   1 +
>   target/mips/kvm.c         |   5 ++
>   target/ppc/kvm.c          |   5 ++
>   target/s390x/kvm.c        |   5 ++
>   18 files changed, 286 insertions(+), 4 deletions(-)
> 

Queued, thanks.

Paolo


WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Connor Kuehl <ckuehl@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Jiri Slaby <jslaby@suse.cz>,
	Aurelien Jarno <aurelien@aurel32.net>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v6 0/6] Qemu SEV-ES guest support
Date: Fri, 5 Feb 2021 11:59:40 +0100	[thread overview]
Message-ID: <9cfe8d87-c440-6ce8-7b1c-beb46e17c173@redhat.com> (raw)
In-Reply-To: <cover.1611682609.git.thomas.lendacky@amd.com>

On 26/01/21 18:36, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
> 
> This patch series provides support for launching an SEV-ES guest.
> 
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
> 
> In order to allow a hypervisor to perform functions on behalf of a guest,
> there is architectural support for notifying a guest's operating system
> when certain types of VMEXITs are about to occur. This allows the guest to
> selectively share information with the hypervisor to satisfy the requested
> function. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
> 
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
> 
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
> 
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
> 
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
> 
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
>      https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
> 
> Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
> Cc: Aurelien Jarno <aurelien@aurel32.net>
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Eduardo Habkost <ehabkost@redhat.com>
> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> 
> ---
> 
> These patches are based on commit:
> 9cd69f1a27 ("Merge remote-tracking branch 'remotes/stefanberger/tags/pull-tpm-2021-01-25-1' into staging")
> 
> Additionally, these patches pre-req the following patch series that has
> not yet been accepted into the Qemu tree:
> 
> [PATCH v2 0/2] sev: enable secret injection to a self described area in OVMF
>    https://lore.kernel.org/qemu-devel/20201214154429.11023-1-jejb@linux.ibm.com/
> 
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v14
> 
> Changes since v5:
> - Rework the reset prevention patch to not issue the error message if the
>    --no-reboot option has been specified for SEV-ES guests.
> 
> Changes since v4:
> - Add support for an updated Firmware GUID table implementation, that
>    is now present in OVMF SEV-ES firmware, when searching for the reset
>    vector information. The code will check for the new implementation
>    first, followed by the original implementation to maintain backward
>    compatibility.
> 
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
>    at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
> 
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
> 
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
> 
> Tom Lendacky (6):
>    sev/i386: Add initial support for SEV-ES
>    sev/i386: Require in-kernel irqchip support for SEV-ES guests
>    sev/i386: Allow AP booting under SEV-ES
>    sev/i386: Don't allow a system reset under an SEV-ES guest
>    kvm/i386: Use a per-VM check for SMM capability
>    sev/i386: Enable an SEV-ES guest based on SEV policy
> 
>   accel/kvm/kvm-all.c       |  69 +++++++++++++++++++++
>   accel/stubs/kvm-stub.c    |   5 ++
>   hw/i386/pc_sysfw.c        |  10 ++-
>   include/sysemu/cpus.h     |   2 +
>   include/sysemu/hw_accel.h |   5 ++
>   include/sysemu/kvm.h      |  26 ++++++++
>   include/sysemu/sev.h      |   3 +
>   softmmu/cpus.c            |   5 ++
>   softmmu/runstate.c        |   3 +
>   target/arm/kvm.c          |   5 ++
>   target/i386/cpu.c         |   1 +
>   target/i386/kvm/kvm.c     |  10 ++-
>   target/i386/sev-stub.c    |   6 ++
>   target/i386/sev.c         | 124 +++++++++++++++++++++++++++++++++++++-
>   target/i386/sev_i386.h    |   1 +
>   target/mips/kvm.c         |   5 ++
>   target/ppc/kvm.c          |   5 ++
>   target/s390x/kvm.c        |   5 ++
>   18 files changed, 286 insertions(+), 4 deletions(-)
> 

Queued, thanks.

Paolo



  parent reply	other threads:[~2021-02-05 11:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 17:36 [PATCH v6 0/6] Qemu SEV-ES guest support Tom Lendacky
2021-01-26 17:36 ` Tom Lendacky
2021-01-26 17:36 ` [PATCH v6 1/6] sev/i386: Add initial support for SEV-ES Tom Lendacky
2021-01-26 17:36   ` Tom Lendacky
2021-01-29 17:39   ` Venu Busireddy
2021-01-29 17:39     ` Venu Busireddy
2021-01-26 17:36 ` [PATCH v6 2/6] sev/i386: Require in-kernel irqchip support for SEV-ES guests Tom Lendacky
2021-01-26 17:36   ` Tom Lendacky
2021-01-29 17:41   ` Venu Busireddy
2021-01-29 17:41     ` Venu Busireddy
2021-01-26 17:36 ` [PATCH v6 3/6] sev/i386: Allow AP booting under SEV-ES Tom Lendacky
2021-01-26 17:36   ` Tom Lendacky
2021-01-29 17:44   ` Venu Busireddy
2021-01-29 17:44     ` Venu Busireddy
2021-02-01 18:48     ` Tom Lendacky
2021-02-01 18:48       ` Tom Lendacky
2021-01-26 17:36 ` [PATCH v6 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest Tom Lendacky
2021-01-26 17:36   ` Tom Lendacky
2021-01-29 17:44   ` Venu Busireddy
2021-01-29 17:44     ` Venu Busireddy
2021-01-26 17:36 ` [PATCH v6 5/6] kvm/i386: Use a per-VM check for SMM capability Tom Lendacky
2021-01-26 17:36   ` Tom Lendacky
2021-01-29 17:46   ` Venu Busireddy
2021-01-29 17:46     ` Venu Busireddy
2021-01-26 17:36 ` [PATCH v6 6/6] sev/i386: Enable an SEV-ES guest based on SEV policy Tom Lendacky
2021-01-26 17:36   ` Tom Lendacky
2021-01-29 17:46   ` Venu Busireddy
2021-01-29 17:46     ` Venu Busireddy
2021-02-05 10:59 ` Paolo Bonzini [this message]
2021-02-05 10:59   ` [PATCH v6 0/6] Qemu SEV-ES guest support Paolo Bonzini
2021-02-08 15:48   ` Tom Lendacky
2021-02-08 15:48     ` Tom Lendacky
2021-02-08 16:31     ` Paolo Bonzini
2021-02-08 16:31       ` Paolo Bonzini
2021-02-08 17:35       ` Tom Lendacky
2021-02-08 17:35         ` Tom Lendacky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9cfe8d87-c440-6ce8-7b1c-beb46e17c173@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aleksandar.rikalo@syrmia.com \
    --cc=aurelien@aurel32.net \
    --cc=brijesh.singh@amd.com \
    --cc=ckuehl@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jslaby@suse.cz \
    --cc=kvm@vger.kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=rth@twiddle.net \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.