kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: "Jörg Rödel" <jroedel@suse.de>
Cc: amd-sev-snp@lists.suse.com, linux-coco@lists.linux.dev,
	kvm@vger.kernel.org
Subject: Re: [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP
Date: Tue, 21 Mar 2023 09:43:48 -0400	[thread overview]
Message-ID: <c2e8af835723c453adaba4b66db533a158076bbf.camel@linux.ibm.com> (raw)
In-Reply-To: <ZBmmjlNdBwVju6ib@suse.de>

On Tue, 2023-03-21 at 13:43 +0100, Jörg Rödel wrote:
> Hi James,
> 
> On Tue, Mar 21, 2023 at 07:09:40AM -0400, James Bottomley wrote:
> > Since this a fork of the AMD svsm code
> > (https://github.com/AMDESE/linux-svsm/), is it intended to be a
> > permanent fork, or are you going to be submitting your additions
> > back upstream like we're trying to do for our initial vTPM
> > prototype? From the community point of view, having two different
> > SVSM code bases and having to choose which one to develop against
> > is going to be very confusing ...
> 
> The COCONUT-SVSM was and is a separate project and not a fork of AMDs
> linux-svsm. Some code was ported from our code-base to linux-svsm in
> the past, namely the SpinLock implementation and the memory
> allocators.

Well at the time you submitted the pull request, Coconut wasn't public,
so I don't think it looked like a port from a separate code base when
it happened.  But anyway, I'm not so interested in who is based on
whom, I'm more interested in how we avoid dividing our efforts on
confidential computing going forwards.

> What the project also shares with linux-svsm is the support code in
> the Linux kernel (host and guest) and the EDK2 changes needed to
> launch an SVSM.
> 
> But besides that the two code-bases are different, using a different
> build approach and different launch protocol. The goals we have with
> our SVSM are hard to achieve with the linux-svsm code-base, so a
> merge does not make sense at this point.

Could you describe these incompatible goals and explain why you think
they are incompatible (as in why you and AMD don't think you can agree
on it)?  That would help the rest of us understand where the two SVSM
implementations fit in our ongoing plans.

Regards,

James


  reply	other threads:[~2023-03-21 13:44 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21  9:29 [ANNOUNCEMENT] COCONUT Secure VM Service Module for SEV-SNP Jörg Rödel
2023-03-21 11:09 ` James Bottomley
2023-03-21 12:43   ` Jörg Rödel
2023-03-21 13:43     ` James Bottomley [this message]
2023-03-21 15:14       ` Jörg Rödel
2023-03-21 17:48         ` Dr. David Alan Gilbert
2023-03-21 18:50           ` Jörg Rödel
2023-03-21 20:05         ` James Bottomley
2023-03-22  1:29           ` Marc Orr
2023-03-22 17:57             ` Daniel P. Berrangé
2023-03-22  9:15           ` Jörg Rödel
2023-03-22 18:07             ` Daniel P. Berrangé
2023-03-22 18:24               ` Dionna Amalie Glaze
2023-03-21 15:06 ` Dr. David Alan Gilbert
2023-03-21 15:25   ` Jörg Rödel
2023-03-21 16:56     ` Dr. David Alan Gilbert
2023-03-21 19:03       ` Jörg Rödel
2023-03-21 19:53         ` Dr. David Alan Gilbert
2023-03-22  9:19           ` Jörg Rödel
2023-03-22  9:43             ` Alexander Graf
2023-03-22 10:34               ` Dr. David Alan Gilbert
2023-03-22 17:37                 ` Dionna Amalie Glaze
2023-03-22 17:47                   ` Dr. David Alan Gilbert
2023-03-22 21:53                     ` James Bottomley
2023-04-11 19:57 ` Tom Lendacky
2023-04-11 20:01   ` Dionna Amalie Glaze
2023-04-13 16:57   ` James Bottomley
2023-04-14  9:00     ` Jörg Rödel
2023-05-02 23:03 ` Tom Lendacky
2023-05-03 12:26   ` Jörg Rödel
2023-05-03 15:24     ` Dionna Amalie Glaze
2023-05-03 15:43       ` James Bottomley
2023-05-03 16:10       ` Daniel P. Berrangé
2023-05-03 16:51     ` Claudio Carvalho
2023-05-03 17:16       ` Alexander Graf
2023-05-05 15:34       ` Jörg Rödel
2023-05-05 15:47         ` Daniel P. Berrangé
2023-05-04 17:04     ` James Bottomley
2023-05-05 12:35       ` Christophe de Dinechin
2023-05-06 12:48         ` James Bottomley
2023-05-08  5:16           ` Alexander Graf
2023-05-05 15:02       ` Jörg Rödel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c2e8af835723c453adaba4b66db533a158076bbf.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=amd-sev-snp@lists.suse.com \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).