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
