Re: [PATCH v7 08/13] confidential guest support: Move SEV initialization into arch specific code

[David Gibson]

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

signature.asc
Description: PGP signature