Thread (116 messages) 116 messages, 15 authors, 2022-07-25

Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory

From: Sean Christopherson <seanjc@google.com>
Date: 2022-07-21 21:19:15
Also in: kvm, linux-fsdevel, linux-mm, lkml, qemu-devel

On Thu, Jul 21, 2022, Gupta, Pankaj wrote:
Hi Sean, Chao,

While attempting to solve the pre-boot guest payload/firmware population
into private memory for SEV SNP, retrieved this thread. Have question below:
quoted
quoted
quoted
Requirements & Gaps
-------------------------------------
   - Confidential computing(CC): TDX/SEV/CCA
     * Need support both explicit/implicit conversions.
     * Need support only destructive conversion at runtime.
     * The current patch should just work, but prefer to have pre-boot guest
       payload/firmware population into private memory for performance.
Not just performance in the case of SEV, it's needed there because firmware
only supports in-place encryption of guest memory, there's no mechanism to
provide a separate buffer to load into guest memory at pre-boot time. I
think you're aware of this but wanted to point that out just in case.
I view it as a performance problem because nothing stops KVM from copying from
userspace into the private fd during the SEV ioctl().  What's missing is the
ability for userspace to directly initialze the private fd, which may or may not
avoid an extra memcpy() depending on how clever userspace is.
Can you please elaborate more what you see as a performance problem? And
possible ways to solve it?
Oh, I'm not saying there actually _is_ a performance problem.  What I'm saying is
that in-place encryption is not a functional requirement, which means it's purely
an optimization, and thus we should other bother supporting in-place encryption
_if_ it would solve a performane bottleneck.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help