quoted

quoted

quoted

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