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