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

[Gupta, Pankaj]

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

Understood. Thank you!

Best regards,
Pankaj