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>
---
accel/kvm/kvm-all.c | 14 --------------
accel/kvm/sev-stub.c | 4 ++--
target/i386/kvm/kvm.c | 12 ++++++++++++
target/i386/sev.c | 7 ++++++-
4 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index c5b0750fd0..adf27c1864 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2177,20 +2177,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..e8b9dc48a2 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,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
uint64_t shadow_mem;
int ret;
struct utsname utsname;
+ Error *local_err = NULL;
+
+ /*
+ * if memory encryption object is specified then initialize the
+ * memory encryption context (no-op otherwise)
+ */
+ 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 3d94635397..aa79cacabe 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__);
--
2.29.2
On Thu, 14 Jan 2021 10:58:06 +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>
> ---
> accel/kvm/kvm-all.c | 14 --------------
> accel/kvm/sev-stub.c | 4 ++--
> target/i386/kvm/kvm.c | 12 ++++++++++++
> target/i386/sev.c | 7 ++++++-
> 4 files changed, 20 insertions(+), 17 deletions(-)
>
(...)
> @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> uint64_t shadow_mem;
> int ret;
> struct utsname utsname;
> + Error *local_err = NULL;
> +
> + /*
> + * if memory encryption object is specified then initialize the
> + * memory encryption context (no-op otherwise)
> + */
> + ret = sev_kvm_init(ms->cgs, &local_err);
Maybe still leave a comment here, as the code will still need to be
modified to handle non-SEV x86 mechanisms?
> + 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 3d94635397..aa79cacabe 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);
This looks a bit ugly; maybe we want the generic code to generate a
separate version of the cast macro that doesn't assert? Just cosmetics,
though.
> 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__);
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
On Fri, Jan 15, 2021 at 02:24:25PM +0100, Cornelia Huck wrote:
> On Thu, 14 Jan 2021 10:58:06 +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>
> > ---
> > accel/kvm/kvm-all.c | 14 --------------
> > accel/kvm/sev-stub.c | 4 ++--
> > target/i386/kvm/kvm.c | 12 ++++++++++++
> > target/i386/sev.c | 7 ++++++-
> > 4 files changed, 20 insertions(+), 17 deletions(-)
> >
>
> (...)
>
> > @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > uint64_t shadow_mem;
> > int ret;
> > struct utsname utsname;
> > + Error *local_err = NULL;
> > +
> > + /*
> > + * if memory encryption object is specified then initialize the
> > + * memory encryption context (no-op otherwise)
> > + */
> > + ret = sev_kvm_init(ms->cgs, &local_err);
>
> Maybe still leave a comment here, as the code will still need to be
> modified to handle non-SEV x86 mechanisms?
Uh.. I'm confused.. this hunk is adding a comment, not removing one..
>
> > + 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 3d94635397..aa79cacabe 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);
>
> This looks a bit ugly; maybe we want the generic code to generate a
> separate version of the cast macro that doesn't assert? Just cosmetics,
> though.
I tend to the view that the clunkiness of this textually is
outweighted by using object_dynamic_cast() which has well known
semantics, rather than requiring someone reading the code to
understand another intermediate macro.
> > 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__);
>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Mon, 18 Jan 2021 14:03:08 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Jan 15, 2021 at 02:24:25PM +0100, Cornelia Huck wrote:
> > On Thu, 14 Jan 2021 10:58:06 +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>
> > > ---
> > > accel/kvm/kvm-all.c | 14 --------------
> > > accel/kvm/sev-stub.c | 4 ++--
> > > target/i386/kvm/kvm.c | 12 ++++++++++++
> > > target/i386/sev.c | 7 ++++++-
> > > 4 files changed, 20 insertions(+), 17 deletions(-)
> > >
> >
> > (...)
> >
> > > @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > > uint64_t shadow_mem;
> > > int ret;
> > > struct utsname utsname;
> > > + Error *local_err = NULL;
> > > +
> > > + /*
> > > + * if memory encryption object is specified then initialize the
> > > + * memory encryption context (no-op otherwise)
> > > + */
> > > + ret = sev_kvm_init(ms->cgs, &local_err);
> >
> > Maybe still leave a comment here, as the code will still need to be
> > modified to handle non-SEV x86 mechanisms?
>
> Uh.. I'm confused.. this hunk is adding a comment, not removing one..
Yes, but there was a "TODO: handle non-SEV" comment before. This will
probably need some massaging if we add Intel mechanisms?
>
> >
> > > + 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");
On Mon, Jan 18, 2021 at 09:03:36AM +0100, Cornelia Huck wrote: > On Mon, 18 Jan 2021 14:03:08 +1100 > David Gibson <david@gibson.dropbear.id.au> wrote: > > > On Fri, Jan 15, 2021 at 02:24:25PM +0100, Cornelia Huck wrote: > > > On Thu, 14 Jan 2021 10:58:06 +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> > > > > --- > > > > accel/kvm/kvm-all.c | 14 -------------- > > > > accel/kvm/sev-stub.c | 4 ++-- > > > > target/i386/kvm/kvm.c | 12 ++++++++++++ > > > > target/i386/sev.c | 7 ++++++- > > > > 4 files changed, 20 insertions(+), 17 deletions(-) > > > > > > > > > > (...) > > > > > > > @@ -2135,6 +2136,17 @@ int kvm_arch_init(MachineState *ms, KVMState *s) > > > > uint64_t shadow_mem; > > > > int ret; > > > > struct utsname utsname; > > > > + Error *local_err = NULL; > > > > + > > > > + /* > > > > + * if memory encryption object is specified then initialize the > > > > + * memory encryption context (no-op otherwise) > > > > + */ > > > > + ret = sev_kvm_init(ms->cgs, &local_err); > > > > > > Maybe still leave a comment here, as the code will still need to be > > > modified to handle non-SEV x86 mechanisms? > > > > Uh.. I'm confused.. this hunk is adding a comment, not removing one.. > > Yes, but there was a "TODO: handle non-SEV" comment before. This will > probably need some massaging if we add Intel mechanisms? Technically, not exactly. New mechanisms would have their own initialization, which might go adjacent to this, or could be somewhere else - the sev_kvm_init() is a no-op if a non-SEV mechanism is selected (currently impossible). The distinction is pretty subtle, though, so I've altered the comment here in a way I hope explains it. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
© 2016 - 2026 Red Hat, Inc.