[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest
From: |
Sean Christopherson |
Subject: |
Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM guest private memory |
Date: |
Thu, 21 Jul 2022 21:19:06 +0000 |
On Thu, Jul 21, 2022, Gupta, Pankaj wrote:
>
> Hi Sean, Chao,
>
> While attempting to solve the pre-boot guest payload/firmware population
> into private memory for SEV SNP, retrieved this thread. Have question below:
>
> > > > Requirements & Gaps
> > > > -------------------------------------
> > > > - Confidential computing(CC): TDX/SEV/CCA
> > > > * Need support both explicit/implicit conversions.
> > > > * Need support only destructive conversion at runtime.
> > > > * 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.