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

David Gibson
2021-01-29T05:09:39Z

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]