Open Stack

Hi James,

That’s very helpful. Thanks!

Sincerely,
Jesse

From: Hunt, James O [mailto:james.o.hunt at intel.com]
Sent: Wednesday, June 20, 2018 4:06 AM
To: Larrew, Jesse <Jesse.Larrew at amd.com>
Cc: Ernst, Eric <eric.ernst at intel.com>; Singh, Brijesh <brijesh.singh at amd.com>; Kaplan, David <David.Kaplan at amd.com>; Hollingsworth, Brent <brent.hollingsworth at amd.com>; Woller, Thomas <thomas.woller at amd.com>; kata-dev at 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 at amd.com<mailto:Jesse.Larrew at 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<http://github.com/intel-go/cpuid>" to Gopkg.toml to pull in your upstream changes.

  See https://github.com/kata-containers/community/blob/master/VENDORING.md#vendor-a-newly-imported-package

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

  See https://github.com/kata-containers/community/blob/master/VENDORING.md#update-a-vendored-package

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 at intel.com<mailto:eric.ernst at intel.com>]
Sent: Wednesday, May 9, 2018 3:45 PM

To: Larrew, Jesse <Jesse.Larrew at amd.com<mailto:Jesse.Larrew at amd.com>>
Cc: Jon Olson <jonolson at google.com<mailto:jonolson at google.com>>; Singh, Brijesh <brijesh.singh at amd.com<mailto:brijesh.singh at amd.com>>; Kaplan, David <David.Kaplan at amd.com<mailto:David.Kaplan at amd.com>>; Hollingsworth, Brent <brent.hollingsworth at amd.com<mailto:brent.hollingsworth at amd.com>>; kata-dev at lists.katacontainers.io<mailto:kata-dev at lists.katacontainers.io>; Woller, Thomas <thomas.woller at amd.com<mailto:thomas.woller at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180620/385c7801/attachment-0001.html>