Open Stack

> From: Castelino, Manohar R [mailto:manohar.r.castelino at intel.com]
> Sent: Friday, February 23, 2018 3:53 PM
> To: Larrew, Jesse <Jesse.Larrew at amd.com>; Samuel Ortiz
> <sameo at linux.intel.com>
> Cc: Hollingsworth, Brent <brent.hollingsworth at amd.com>; Woller, Thomas
> <thomas.woller at amd.com>; Kaplan, David <David.Kaplan at amd.com>; kata-
> dev at lists.katacontainers.io
> Subject: RE: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)
> 
> Jesse,
> 
> > On EPYC, our IOMMU doesn't yet support SEV, so DMA to/from devices
> needs
> > to be done using unencrypted pages. It was easy to implement this using
> the
> > bounce buffers provided by SWIOTLB. As you guessed, a quick change to
> > vring_use_dma_api() got virtio support working properly:
> 
> Clear Containers today supports direct device assignment via SRIOV.
> This requires pre-allocation and pinning of VM memory.
> Will this continue to work?
> 
> Also we have been working on reverse ballooning. i.e. free unused memory
> from the VM back to the host. Is there is a way to get this to work with
> encrypted memory
> 
> For more details about the patches
> https://gist.github.com/sboeuf/fc71f0218a81997251ee0d7668df2bd9
> 
> -manohar
> 
> 

Hi Manohar,

SEV also requires the guest memory to be pre-allocated and pinned [1], so that's not a problem. As long as the PF drivers in the guest are using the dma apis, everything should continue to work.

Similarly, the reverse ballooning patches should also work with SEV. In fact, I would argue that SEV compliments this feature by ensuring that physical page contents aren't exposed to the host when the guest uses MADV_FREE. I've CC'ed our KVM expert, Brijesh Singh, just in case he sees something that I missed.

Sincerely,
Jesse

[1] In order to ensure that memory blocks with identical data will encrypt to different ciphertext, SEV mixes the physical address into the encryption algorithm. As a result, if a page of memory is moved to a different physical address, it will not decrypt properly. This also defeats block-move attacks on the guest memory, but it also requires all guest memory to be pinned.