[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2171cf37-ea82-25c5-ad85-a80519525045@kernel.org>
Date: Fri, 22 Jul 2022 20:09:23 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Sean Christopherson <seanjc@...gle.com>,
"Gupta, Pankaj" <pankaj.gupta@....com>
Cc: Chao Peng <chao.p.peng@...ux.intel.com>,
Quentin Perret <qperret@...gle.com>,
Michael Roth <michael.roth@....com>,
Steven Price <steven.price@....com>,
kvm list <kvm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
Linux API <linux-api@...r.kernel.org>, qemu-devel@...gnu.org,
Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Hugh Dickins <hughd@...gle.com>,
Jeff Layton <jlayton@...nel.org>,
"J . Bruce Fields" <bfields@...ldses.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mike Rapoport <rppt@...nel.org>,
"Maciej S . Szmigiero" <mail@...iej.szmigiero.name>,
Vlastimil Babka <vbabka@...e.cz>,
Vishal Annapurve <vannapurve@...gle.com>,
Yu Zhang <yu.c.zhang@...ux.intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
"Nakajima, Jun" <jun.nakajima@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
David Hildenbrand <david@...hat.com>,
Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
nikunj@....com, ashish.kalra@....com
Subject: Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM
guest private memory
On 7/21/22 14:19, Sean Christopherson wrote:
> On Thu, Jul 21, 2022, Gupta, Pankaj wrote:
>>
>>> 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.
Powered by blists - more mailing lists