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

[Gupta, Pankaj]

> > > > 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.
>
> Even if we end up having a performance problem, I think we need to 
> understand the workloads that we want to optimize before getting too 
> excited about designing a speedup.
>
> In particular, there's (depending on the specific technology, perhaps, 
> and also architecture) a possible tradeoff between trying to reduce 
> copying and trying to reduce unmapping and the associated flushes.  If a 
> user program maps an fd, populates it, and then converts it in place 
> into private memory (especially if it doesn't do it in a single shot), 
> then that memory needs to get unmapped both from the user mm and 
> probably from the kernel direct map.  On the flip side, it's possible to 
> imagine an ioctl that does copy-and-add-to-private-fd that uses a 
> private mm and doesn't need any TLB IPIs.
>
> All of this is to say that trying to optimize right now seems quite 
> premature to me.

Agree to it. Thank you for explaining!

Thanks,
Pankaj