<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 23, 2018 at 4:42 PM Larrew, Jesse <<a href="mailto:Jesse.Larrew@amd.com">Jesse.Larrew@amd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Castelino, Manohar R [mailto:<a href="mailto:manohar.r.castelino@intel.com" target="_blank">manohar.r.castelino@intel.com</a>]<br>
> Sent: Friday, February 23, 2018 3:53 PM<br>
> To: Larrew, Jesse <<a href="mailto:Jesse.Larrew@amd.com" target="_blank">Jesse.Larrew@amd.com</a>>; Samuel Ortiz<br>
> <<a href="mailto:sameo@linux.intel.com" target="_blank">sameo@linux.intel.com</a>><br>
> Cc: Hollingsworth, Brent <<a href="mailto:brent.hollingsworth@amd.com" target="_blank">brent.hollingsworth@amd.com</a>>; Woller, Thomas<br>
> <<a href="mailto:thomas.woller@amd.com" target="_blank">thomas.woller@amd.com</a>>; Kaplan, David <<a href="mailto:David.Kaplan@amd.com" target="_blank">David.Kaplan@amd.com</a>>; kata-<br>
> <a href="mailto:dev@lists.katacontainers.io" target="_blank">dev@lists.katacontainers.io</a><br>
> Subject: RE: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)<br>
><br>
> Jesse,<br>
><br>
> > On EPYC, our IOMMU doesn't yet support SEV, so DMA to/from devices<br>
> needs<br>
> > to be done using unencrypted pages. It was easy to implement this using<br>
> the<br>
> > bounce buffers provided by SWIOTLB. As you guessed, a quick change to<br>
> > vring_use_dma_api() got virtio support working properly:<br>
><br>
> Clear Containers today supports direct device assignment via SRIOV.<br>
> This requires pre-allocation and pinning of VM memory.<br>
> Will this continue to work?<br>
><br>
> Also we have been working on reverse ballooning. i.e. free unused memory<br>
> from the VM back to the host. Is there is a way to get this to work with<br>
> encrypted memory<br>
><br>
> For more details about the patches<br>
> <a href="https://gist.github.com/sboeuf/fc71f0218a81997251ee0d7668df2bd9" rel="noreferrer" target="_blank">https://gist.github.com/sboeuf/fc71f0218a81997251ee0d7668df2bd9</a><br>
><br>
> -manohar<br>
><br>
><br>
<br>
Hi Manohar,<br>
<br>
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.<br></blockquote><div><br></div><div>That's surprising -- I can see where reclaim would be challenging without something like a balloon, but why must the be initially backed? What happens if you leave a page unbacked and attempt to lazily back it on an EPT fault?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
Sincerely,<br>
Jesse<br>
<br>
[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.<br>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</blockquote></div></div>