Hi James,

 

That’s very helpful. Thanks!

 

Sincerely,

Jesse

 

From: Hunt, James O [mailto:james.o.hunt@intel.com]
Sent: Wednesday, June 20, 2018 4:06 AM
To: Larrew, Jesse <Jesse.Larrew@amd.com>
Cc: Ernst, Eric <eric.ernst@intel.com>; Singh, Brijesh <brijesh.singh@amd.com>; Kaplan, David <David.Kaplan@amd.com>; Hollingsworth, Brent <brent.hollingsworth@amd.com>; Woller, Thomas <thomas.woller@amd.com>; kata-dev@lists.katacontainers.io
Subject: Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)

 

Hi Jesse,

 

 

2018-06-19 18:57 GMT+01:00 Larrew, Jesse <Jesse.Larrew@amd.com>:

Hi Eric,

 

We’re still working on setting up the CI server, but we’ve decided to make the SEV patches available on our github repo so folks can kick the tires, so to speak.

\o/ - great!

 

 

The SEV patches require a new dependency in the vendor tree and updates a few others:

  1. intel-go/cpuid (new dependency),
  2. intel/govmm,
  3. virtcontainers

 

To submit a PR to kata-runtime, should I first fork each of the above projects and submit PRs against them, then point to those PRs when I submit to kata? This is the first Go project that I’ve contributed to, so I’m not sure what the protocol is. Any tips would be helpful. Thanks!

For (1) and (2), yes, you'll need to click "fork" on https://github.com/intel-go/cpuid and https://github.com/intel/govmm, and then raise PRs on those two projects.

 

Once both those PRs have landed, since virtcontainers is now part of the Kata runtime you can then raise a PR on https://github.com/kata-containers/runtime for the changes you need to make to https://github.com/kata-containers/runtime/tree/master/virtcontainers.

 

As part of that change, you'll need to update the runtime vendoring to pull in (1) and (2):

 

- Add "github.com/intel-go/cpuid" to Gopkg.toml to pull in your upstream changes.

 

 

- Update the commit for "github.com/intel/govmm" in Gopkg.toml to pull in your upstream changes.

 

 

Note that you can *probably* get away with updating the Gopkg.toml file once for both changes (meaning you only need to run "dep ensure" once) and having all the changes on a single commit.

 

HTH.

 

Cheers,

 

James

 

 

Sincerely,

Jesse

 

From: Ernst, Eric [mailto:eric.ernst@intel.com]
Sent: Wednesday, May 9, 2018 3:45 PM


To: Larrew, Jesse <Jesse.Larrew@amd.com>
Cc: Jon Olson <jonolson@google.com>; Singh, Brijesh <brijesh.singh@amd.com>; Kaplan, David <David.Kaplan@amd.com>; Hollingsworth, Brent <brent.hollingsworth@amd.com>; kata-dev@lists.katacontainers.io; Woller, Thomas <thomas.woller@amd.com>
Subject: Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)

 

Hey Jesse,

 

I had the chance to meet Brent @ Red Hat Summit yesterday, and this was a good reminder to reach out regarding SEV support in Kata.

 

First, as expressed to Brent, this is a sweet use case.

 

Second, one of the things that has come to mind for me is how we can verify. 

 

Our CI is running on a mix of baremetal machines for metrics and machines in the cloud (via Azure) for functional testing.  For other architectures, and including this feature, it’d be best to have this exercised in CI.  Basically, I’d want to make sure we can replicate the CI on a single AMD Epyc (or other SEV enabled system) which could help gate our CI process.  We have the test setup designed to be easily reproduced, and can work together on getting this setup, assuming we find a machine which  this can run on.

 

With this feature enabled in our CI, we’d be able to guarantee that it continues to work (and if it fails, it should be an easy fix).

 

Thanks,
Eric