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: > > > > > 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.
