From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D441AC432BE for ; Fri, 27 Aug 2021 22:29:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 72ED360E99 for ; Fri, 27 Aug 2021 22:29:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 72ED360E99 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 03E3D8D0001; Fri, 27 Aug 2021 18:29:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2F8E6B0071; Fri, 27 Aug 2021 18:29:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF7528D0001; Fri, 27 Aug 2021 18:29:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id C5CC76B006C for ; Fri, 27 Aug 2021 18:29:00 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7E814289DC for ; Fri, 27 Aug 2021 22:29:00 +0000 (UTC) X-FDA: 78522302040.11.4154B88 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf03.hostedemail.com (Postfix) with ESMTP id 44A4C3000096 for ; Fri, 27 Aug 2021 22:29:00 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id e15so4805657plh.8 for ; Fri, 27 Aug 2021 15:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Kcz/OcOk78cxC9xSl0rIRLhu0Wg6VNLvHKoD96Y0zU4=; b=JSfG3SMSCC9NBv4yyAkJXKMCG8K50uUZ9UT0zpseTaWzxZqw7s2EkKqGCUkqY2hEEO rTAN5Wi3ymSOi052g5pSN+AYYo2jhO/xEnmmSqM83ebsws8hkJXfqzXn5hmRkEaeRHXA tzfo43wq7M4o16hRkaVL/5ait942tSAHvDNMqYnAkg3QXfq71LkI6xV86h9PyzZVVcpn p09Z7AznbqxQrUlt77vweBgDktY/D8IaBnrWZqY7Gz1E22yuuoHGV/Ci1ICTIEHARo7U xZOjtz78b+ZRmwN2VCOjYpDOISpwNFmKomLi7QW8XakSn7tWhLJ9jAeWAYvJiBwm7wMb T5DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Kcz/OcOk78cxC9xSl0rIRLhu0Wg6VNLvHKoD96Y0zU4=; b=qHvwwOOEcPtUVbK/0/PF/HB6Xyt/OnoioM2EqvChCfztLpoMC2tm29ctC9TH2UM4uC Q7DLqgJJ7s8gfOUmelueA80jhUIuWK5Bs8ZydjOseSnTA25uo7Q0xlnBSkggPRdZQ/wx kqL8IUINsMZGSNBmsk4wr0yNuvBgFVF1LuWVzLOedWLgZ2g9f3LSS7yDZkGO+GvUEb3v LxAg95wf5s7xnCY1+YgG7Q9qzCM1ImZHHq2Bs62qfuNa6Z2I4RnEToRtU2VUY+/wBszL dKy+KQf755H2GGww78P2nSkYQgN03PSyEkLVC0EHoHt8Jf3Zle9e5WJ2phU48iQIHCDk /CUg== X-Gm-Message-State: AOAM532K6zp6XbW4Gnr6ajr59hrsoyDv4HnyYm3ShvIlXLKNnKW1YVqM aJjxRy/r1lgzkWOZOO4vVvDcSg== X-Google-Smtp-Source: ABdhPJxkNLsbF9Xpeyfdy+wpf433FXdU+W+o0pck9+d5DrE9KJ2PeRK+v2c385q0qdLbxd5O5brffg== X-Received: by 2002:a17:90a:1957:: with SMTP id 23mr12592991pjh.141.1630103339086; Fri, 27 Aug 2021 15:28:59 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id a23sm2263182pfo.120.2021.08.27.15.28.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 15:28:58 -0700 (PDT) Date: Fri, 27 Aug 2021 22:28:54 +0000 From: Sean Christopherson To: Andy Lutomirski Cc: David Hildenbrand , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm list , Linux Kernel Mailing List , Borislav Petkov , Andrew Morton , Joerg Roedel , Andi Kleen , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , "Peter Zijlstra (Intel)" , Ingo Molnar , Varad Gautam , Dario Faggioli , the arch/x86 maintainers , linux-mm@kvack.org, linux-coco@lists.linux.dev, "Kirill A. Shutemov" , "Kirill A . Shutemov" , Sathyanarayanan Kuppuswamy , Dave Hansen , Yu Zhang Subject: Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: References: <20210824005248.200037-1-seanjc@google.com> <307d385a-a263-276f-28eb-4bc8dd287e32@redhat.com> <40af9d25-c854-8846-fdab-13fe70b3b279@kernel.org> <73319f3c-6f5e-4f39-a678-7be5fddd55f2@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73319f3c-6f5e-4f39-a678-7be5fddd55f2@www.fastmail.com> Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=JSfG3SMS; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of seanjc@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=seanjc@google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 44A4C3000096 X-Stat-Signature: zjtazpkmt1af777fokawhcu3uir7ospo X-HE-Tag: 1630103340-501794 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 27, 2021, Andy Lutomirski wrote: > > On Thu, Aug 26, 2021, at 2:26 PM, David Hildenbrand wrote: > > On 26.08.21 19:05, Andy Lutomirski wrote: > > > > Oof. That's quite a requirement. What's the point of the VMA once all > > > this is done? > > > > You can keep using things like mbind(), madvise(), ... and the GUP code > > with a special flag might mostly just do what you want. You won't have > > to reinvent too many wheels on the page fault logic side at least. Ya, Kirill's RFC more or less proved a special GUP flag would indeed Just Work. However, the KVM page fault side of things would require only a handful of small changes to send private memslots down a different path. Compared to the rest of the enabling, it's quite minor. The counter to that is other KVM architectures would need to learn how to use the new APIs, though I suspect that there will be a fair bit of arch enabling regardless of what route we take. > You can keep calling the functions. The implementations working is a > different story: you can't just unmap (pte_numa-style or otherwise) a private > guest page to quiesce it, move it with memcpy(), and then fault it back in. Ya, I brought this up in my earlier reply. Even the initial implementation (without real NUMA support) would likely be painful, e.g. the KVM TDX RFC/PoC adds dedicated logic in KVM to handle the case where NUMA balancing zaps a _pinned_ page and then KVM fault in the same pfn. It's not thaaat ugly, but it's arguably more invasive to KVM's page fault flows than a new fd-based private memslot scheme.