Messages in this thread | | | Date | Mon, 25 Jul 2022 11:19:02 +0200 | Subject | Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory | From | "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
| |