| Message ID | 20210113235811.1909610-9-david@gibson.dropbear.id.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Generalize memory encryption models | expand |
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> >
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.
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__);
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(-)