From: Greg Kurz <groug@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: <dgilbert@redhat.com>, <pair@us.ibm.com>, <qemu-devel@nongnu.org>,
<brijesh.singh@amd.com>, <pasic@linux.ibm.com>,
<pragyansri.pathi@intel.com>, <richard.henderson@linaro.org>,
<berrange@redhat.com>, David Hildenbrand <david@redhat.com>,
<mdroth@linux.vnet.ibm.com>, <kvm@vger.kernel.org>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
<pbonzini@redhat.com>, <mtosatti@redhat.com>,
<borntraeger@de.ibm.com>, Cornelia Huck <cohuck@redhat.com>,
<qemu-ppc@nongnu.org>, <qemu-s390x@nongnu.org>,
<thuth@redhat.com>, <mst@redhat.com>, <frankja@linux.ibm.com>,
<jun.nakajima@intel.com>, <andi.kleen@intel.com>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH v8 08/13] confidential guest support: Move SEV initialization into arch specific code
Date: Wed, 3 Feb 2021 17:19:32 +0100 [thread overview]
Message-ID: <20210203171932.1aff3727@bahia.lan> (raw)
In-Reply-To: <20210202041315.196530-9-david@gibson.dropbear.id.au>
On Tue, 2 Feb 2021 15:13:10 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> While we've abstracted some (potential) differences between mechanisms for
> securing guest memory, the initialization is still specific to SEV. Given
> that, move it into x86's kvm_arch_init() code, rather than the generic
> kvm_init() code.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
> ---
Reviewed-by: Greg Kurz <groug@kaod.org>
> accel/kvm/kvm-all.c | 14 --------------
> accel/kvm/sev-stub.c | 4 ++--
> target/i386/kvm/kvm.c | 20 ++++++++++++++++++++
> target/i386/sev.c | 7 ++++++-
> 4 files changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index 3d820d0c7d..7150acdbcc 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -2180,20 +2180,6 @@ static int kvm_init(MachineState *ms)
>
> kvm_state = s;
>
> - /*
> - * if memory encryption object is specified then initialize the memory
> - * encryption context.
> - */
> - if (ms->cgs) {
> - Error *local_err = NULL;
> - /* FIXME handle mechanisms other than SEV */
> - ret = sev_kvm_init(ms->cgs, &local_err);
> - if (ret < 0) {
> - error_report_err(local_err);
> - goto err;
> - }
> - }
> -
> ret = kvm_arch_init(ms, s);
> if (ret < 0) {
> goto err;
> diff --git a/accel/kvm/sev-stub.c b/accel/kvm/sev-stub.c
> index 512e205f7f..9587d1b2a3 100644
> --- a/accel/kvm/sev-stub.c
> +++ b/accel/kvm/sev-stub.c
> @@ -17,6 +17,6 @@
>
> int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
> {
> - /* SEV can't be selected if it's not compiled */
> - g_assert_not_reached();
> + /* If we get here, cgs must be some non-SEV thing */
> + return 0;
> }
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index 6dc1ee052d..4788139128 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -42,6 +42,7 @@
> #include "hw/i386/intel_iommu.h"
> #include "hw/i386/x86-iommu.h"
> #include "hw/i386/e820_memory_layout.h"
> +#include "sysemu/sev.h"
>
> #include "hw/pci/pci.h"
> #include "hw/pci/msi.h"
> @@ -2135,6 +2136,25 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> uint64_t shadow_mem;
> int ret;
> struct utsname utsname;
> + Error *local_err = NULL;
> +
> + /*
> + * Initialize SEV context, if required
> + *
> + * If no memory encryption is requested (ms->cgs == NULL) this is
> + * a no-op.
> + *
> + * It's also a no-op if a non-SEV confidential guest support
> + * mechanism is selected. SEV is the only mechanism available to
> + * select on x86 at present, so this doesn't arise, but if new
> + * mechanisms are supported in future (e.g. TDX), they'll need
> + * their own initialization either here or elsewhere.
> + */
> + ret = sev_kvm_init(ms->cgs, &local_err);
> + if (ret < 0) {
> + error_report_err(local_err);
> + return ret;
> + }
>
> if (!kvm_check_extension(s, KVM_CAP_IRQ_ROUTING)) {
> error_report("kvm: KVM_CAP_IRQ_ROUTING not supported by KVM");
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index f9e9b5d8ae..11c9a3cc21 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -664,13 +664,18 @@ sev_vm_state_change(void *opaque, int running, RunState state)
>
> int sev_kvm_init(ConfidentialGuestSupport *cgs, Error **errp)
> {
> - SevGuestState *sev = SEV_GUEST(cgs);
> + SevGuestState *sev
> + = (SevGuestState *)object_dynamic_cast(OBJECT(cgs), TYPE_SEV_GUEST);
> char *devname;
> int ret, fw_error;
> uint32_t ebx;
> uint32_t host_cbitpos;
> struct sev_user_data_status status = {};
>
> + if (!sev) {
> + return 0;
> + }
> +
> ret = ram_block_discard_disable(true);
> if (ret) {
> error_report("%s: cannot disable RAM discard", __func__);
next prev parent reply other threads:[~2021-02-03 16:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 4:13 [PATCH v8 00/13] Generalize memory encryption models David Gibson
2021-02-02 4:13 ` [PATCH v8 01/13] qom: Allow optional sugar props David Gibson
2021-02-02 4:13 ` [PATCH v8 02/13] confidential guest support: Introduce new confidential guest support class David Gibson
2021-02-02 4:13 ` [PATCH v8 03/13] sev: Remove false abstraction of flash encryption David Gibson
2021-02-02 4:13 ` [PATCH v8 04/13] confidential guest support: Move side effect out of machine_set_memory_encryption() David Gibson
2021-02-02 4:13 ` [PATCH v8 05/13] confidential guest support: Rework the "memory-encryption" property David Gibson
2021-02-02 4:13 ` [PATCH v8 06/13] sev: Add Error ** to sev_kvm_init() David Gibson
2021-02-02 4:13 ` [PATCH v8 07/13] confidential guest support: Introduce cgs "ready" flag David Gibson
2021-02-03 10:42 ` Dr. David Alan Gilbert
2021-02-03 16:15 ` Greg Kurz
2021-02-04 2:45 ` David Gibson
2021-02-10 16:25 ` Venu Busireddy
2021-02-11 23:48 ` David Gibson
2021-02-02 4:13 ` [PATCH v8 08/13] confidential guest support: Move SEV initialization into arch specific code David Gibson
2021-02-03 16:19 ` Greg Kurz [this message]
2021-02-02 4:13 ` [PATCH v8 09/13] confidential guest support: Update documentation David Gibson
2021-02-02 4:13 ` [PATCH v8 10/13] spapr: Add PEF based confidential guest support David Gibson
2021-02-03 17:50 ` Greg Kurz
2021-02-04 2:47 ` David Gibson
2021-02-02 4:13 ` [PATCH v8 11/13] spapr: PEF: prevent migration David Gibson
2021-02-02 4:13 ` [PATCH v8 12/13] confidential guest support: Alter virtio default properties for protected guests David Gibson
2021-02-02 23:06 ` Michael S. Tsirkin
2021-02-03 4:53 ` David Gibson
2021-02-02 4:13 ` [PATCH v8 13/13] s390: Recognize confidential-guest-support option David Gibson
2021-02-03 9:05 ` Christian Borntraeger
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=20210203171932.1aff3727@bahia.lan \
--to=groug@kaod.org \
--cc=andi.kleen@intel.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=brijesh.singh@amd.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pair@us.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pragyansri.pathi@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).