lkml.org 
[lkml]   [2022]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory
From

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

\
 
 \ /
  Last update: 2022-07-21 23:37    [W:0.240 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site