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