Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp1163361rwb; Thu, 18 Aug 2022 21:03:26 -0700 (PDT) X-Google-Smtp-Source: AA6agR7xQ9KLHyjU3Iy9YP9lZNqZS8izQsCDLMD8+/KxMm1QPPgTNu8wFIRSpV8KfhryP7/QFYWU X-Received: by 2002:a17:907:2ccb:b0:730:aaca:fc10 with SMTP id hg11-20020a1709072ccb00b00730aacafc10mr3671451ejc.153.1660881805794; Thu, 18 Aug 2022 21:03:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660881805; cv=none; d=google.com; s=arc-20160816; b=v4yWTaOE1KfFMjAAhEi7udA6yaJh9V4hVGJJN68n3pWLWEyGa6E/fwxuM0VC3lyOwa P7CTGb7o0TwaSPx3bzqBB41fT1k+27nkTR2vDjoyH0TlvY+Tq5gKkX3L2xhFzg4/PTW+ qfp6YQjMzkjFZD0MAWCCx09TpXF62rrjdFU3u/wNTEBCUW1H3F0AKPeYKRLxRp3N5xfE g+nh+3pXikkUfY9eptrSzXib4Wp3E6ZdlDdgFmHYTRjJI7gQQKrytWmTUqemEAk9Kifi IcOtq9P0WOEZ6BwnOxsN6E9NyNLhwKbguwXskudQaIuwIcvFelUUAs20QreS/CARTnG/ iYgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=7QWsk1dD79/0D4u0UWDr5UxzCpKhzJRpfIhKUpnpQ+k=; b=Jeqab0vACJ8eDE4XZF/W+hYFifyXPR7+MLo6BuNEBYniHiovhiEqzsouzKRsDxVF+t j4JxTvJZ9tQd3pPe2c/8oUwx8CpSa+a/VfkLJjj5jAMgtkN4/pxEtsRegExi8TWhd5wh LGGIEFBtOaqPcgxYloBFsmWiT2XY/plSP+WmTiIPAkJAf38Wf7nJsUzqVMoY21uwABf/ HBQnJYVakBlGvCwUEI+fp9OODCd813iDt+5n/XeSWtQReyZIZ6dnuU+4AJbyEuZmay6i N+A2OvBL8eKoCzeq8ALHVcc+n9YujXZemmOrH0rOeBeUUaplRvVnWugJb7e1HIrnTh1a kN0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KuaCRRHm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pj21-20020a170906d79500b00738e61897bfsi1801488ejb.233.2022.08.18.21.02.59; Thu, 18 Aug 2022 21:03:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KuaCRRHm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243011AbiHSDi6 (ORCPT + 99 others); Thu, 18 Aug 2022 23:38:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345591AbiHSDiy (ORCPT ); Thu, 18 Aug 2022 23:38:54 -0400 Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C7A75A89F for ; Thu, 18 Aug 2022 20:38:52 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id j17so2549371qtp.12 for ; Thu, 18 Aug 2022 20:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc; bh=7QWsk1dD79/0D4u0UWDr5UxzCpKhzJRpfIhKUpnpQ+k=; b=KuaCRRHm/qV9FFVeqlEN7JryKLX4RwfY1LZIY85W4Q5v1ZzNMZMPFdn7uo+ttUjCVT 1HbFS5hSmTmVaadbykTq/foDTvZk+z2MPmSMfVSyEcM26pLHGI+FT1pagU3qA5YSv6Pe smiTX6ALd4jvtRg4FQeIZu/V5dtCvUlK9QqKG98uq9fHrU0wTxzhMXCNUViHzxNWqeDD tyUgxuRBDcr0kgwcKGkfVF51bYqzSNdXUE3NR9GsMHTj7CAWRw0dTXPSi1QBSeX/tIeL hFZWouaQyyw4UZ3LD6KHID3uW3OYyosgyH7ArN1AA5RlREyiZP0Lm0kDIaJaInosSy0j 3rLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc; bh=7QWsk1dD79/0D4u0UWDr5UxzCpKhzJRpfIhKUpnpQ+k=; b=PbhpkEGIFEOb3cmo2RKr2Xs4PaGo0+1HpCMDIek8jFd3Zd5mfHoUzfwkMpAU3EyNqE 3RBkrU2fVjfLnMFuXEdbHLVKl61iLfyjgaUOEs/WHcRlWg1QHLJlXTxawJ1HUt+kJaeM zQbt5919XWeQaVyNEQJM2GJPawVIapy3oZ3e9VBuYjeo0sF7U7dEBa4DaVpTOHmrAZoY t2UxEqBzjzCsNz3bXMumrLmN8/D/6u3Zfzgaat+fUQ0A+aG0DNsAbCT20+rzRSuHIb29 DasF8/7ii893PuKHaT3AubEqTo7Q3JdDKs+u3w/4jnOVsShuz9FNXA8cgA1fR9PHkQJg NHGw== X-Gm-Message-State: ACgBeo1rHz62C0rQ3MB4lIEmb4cfvup851dOi6c0yZDLYMmxqTsBNcg/ waRwpc/pp+Kis3xjNk1eMimLZQ== X-Received: by 2002:ac8:5ad4:0:b0:344:5e40:7824 with SMTP id d20-20020ac85ad4000000b003445e407824mr5218048qtd.482.1660880331003; Thu, 18 Aug 2022 20:38:51 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id bm25-20020a05620a199900b006b949afa980sm2881193qkb.56.2022.08.18.20.38.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Aug 2022 20:38:50 -0700 (PDT) Date: Thu, 18 Aug 2022 20:38:35 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Sean Christopherson cc: "Kirill A . Shutemov" , Hugh Dickins , Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , "Gupta, Pankaj" Subject: Re: [PATCH v7 00/14] KVM: mm: fd-based approach for supporting KVM guest private memory In-Reply-To: Message-ID: <226ab26d-9aa8-dce2-c7f0-9e3f5b65b63@google.com> References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220818132421.6xmjqduempmxnnu2@box> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Aug 2022, Sean Christopherson wrote: > On Thu, Aug 18, 2022, Kirill A . Shutemov wrote: > > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote: > > > On Wed, 6 Jul 2022, Chao Peng wrote: > > > But since then, TDX in particular has forced an effort into preventing > > > (by flags, seals, notifiers) almost everything that makes it shmem/tmpfs. > > > > > > Are any of the shmem.c mods useful to existing users of shmem.c? No. > > > Is MFD_INACCESSIBLE useful or comprehensible to memfd_create() users? No. > > But QEMU and other VMMs are users of shmem and memfd. The new features certainly > aren't useful for _all_ existing users, but I don't think it's fair to say that > they're not useful for _any_ existing users. Okay, I stand corrected: there exist some users of memfd_create() who will also have use for "INACCESSIBLE" memory. > > > > What use do you have for a filesystem here? Almost none. > > > IIUC, what you want is an fd through which QEMU can allocate kernel > > > memory, selectively free that memory, and communicate fd+offset+length > > > to KVM. And perhaps an interface to initialize a little of that memory > > > from a template (presumably copied from a real file on disk somewhere). > > > > > > You don't need shmem.c or a filesystem for that! > > > > > > If your memory could be swapped, that would be enough of a good reason > > > to make use of shmem.c: but it cannot be swapped; and although there > > > are some references in the mailthreads to it perhaps being swappable > > > in future, I get the impression that will not happen soon if ever. > > > > > > If your memory could be migrated, that would be some reason to use > > > filesystem page cache (because page migration happens to understand > > > that type of memory): but it cannot be migrated. > > > > Migration support is in pipeline. It is part of TDX 1.5 [1]. > > And this isn't intended for just TDX (or SNP, or pKVM). We're not _that_ far off > from being able to use UPM for "regular" VMs as a way to provide defense-in-depth UPM? That's an acronym from your side of the fence, I spy references to it in the mail threads, but haven't tracked down a definition. I'll just take it to mean the fd-based memory we're discussing. > without having to take on the overhead of confidential VMs. At that point, > migration and probably even swap are on the table. Good, the more "flexible" that memory is, the better for competing users of memory. But an fd supplied by KVM gives you freedom to change to a better implementation of allocation underneath, whenever it suits you. Maybe shmem beneath is good from the start, maybe not. Hugh