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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99BF2C28D13 for ; Fri, 19 Aug 2022 22:54:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20F7A8D0001; Fri, 19 Aug 2022 18:54:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 198096B0074; Fri, 19 Aug 2022 18:54:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0113A8D0001; Fri, 19 Aug 2022 18:54:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DF08A6B0073 for ; Fri, 19 Aug 2022 18:54:20 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AC71D140A76 for ; Fri, 19 Aug 2022 22:54:20 +0000 (UTC) X-FDA: 79817847480.25.B3494FF Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf21.hostedemail.com (Postfix) with ESMTP id EC0C61C00A0 for ; Fri, 19 Aug 2022 22:53:07 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id t2-20020a17090a4e4200b001f21572f3a4so6176581pjl.0 for ; Fri, 19 Aug 2022 15:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=bxsKzsoodl9uJzFJZZrQwWPMoj9Im81AmgcsZB9Gfmw=; b=qt/sbuA4OKmJaHmOuxnwa2lGGy6KF/9YxtJ8CEBc62ECZi8/Xq0wY0tron+FkYYdUs X9/M4egtRP0lG6q4e8/IWltnCwwAIXqgqPcmV59AnmXMmxflSpitxJaAXuVmi8jeOb7u ZYWkCe4cfUOnwv+GJ6FAghcaXtVFWtU/VjFn+HZAKAe7LVuzmplI1YXQYgelBcp8xph3 XxuS2HQx3IoH2+jqfCiCLhnkIeS5J/e3C/uJb7oa4kLmq1AEXHLKDQEqspeDUi54j69u rkCsWutnedC/95sn0+Cf9uinQ+8ih+35v91Myr1oidh4MK/5DNYfVzYMeF+QXp50vSUG yQZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=bxsKzsoodl9uJzFJZZrQwWPMoj9Im81AmgcsZB9Gfmw=; b=URQpSSFQOL5o+eRsY/wyF+FIiEBcS71w/C+80WIibrIB/iBk4W35CHNBTxovN/XJ+m VbaHyiRQSqpcmo19FRsRvRjLTJqRDKisdRHAiMIVn4YCUXowsWUvphtwa0dbUO9BG8LR 1qvsBcK0vsz6d/FxUSqnFIjM1f7n92JtFJ536uNaTirZPLyQ2/oeohaPIFI0plKjm3/c HDWmh1tgyn92yshqd30Fh+H+EVgSnpRC1Yc8l8PDvJOjV/JNPfRDbOyUNldQzQ5EFSeX 8F+g1jU4YfcPAvppEj2c87yMAuZIlonNIl3lSBrwHPckLz5c3epPoGsstSKEc6yrHqGp B6eA== X-Gm-Message-State: ACgBeo3xIY4davSv9Kw7uz0w5GsZ8SB3nccGDiyNvgzx0ZpNir8HTF3C jcQf6EUH6BK4cZGi0DVZHVQtrQ== X-Google-Smtp-Source: AA6agR5KPMZr3qT4HevDmGgIVF/eFJY3pV4hPcGRLPDFcNa+kb45vL5UZGGsRX6sXCEs8crjgoKfEw== X-Received: by 2002:a17:90b:1b4a:b0:1f5:5578:6398 with SMTP id nv10-20020a17090b1b4a00b001f555786398mr10621956pjb.122.1660949586764; Fri, 19 Aug 2022 15:53:06 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id h2-20020a63c002000000b0040cb1f55391sm3280975pgg.2.2022.08.19.15.53.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 15:53:06 -0700 (PDT) Date: Fri, 19 Aug 2022 22:53:02 +0000 From: Sean Christopherson To: Hugh Dickins Cc: "Kirill A . Shutemov" , 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 Message-ID: References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220818132421.6xmjqduempmxnnu2@box> <226ab26d-9aa8-dce2-c7f0-9e3f5b65b63@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <226ab26d-9aa8-dce2-c7f0-9e3f5b65b63@google.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660949587; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bxsKzsoodl9uJzFJZZrQwWPMoj9Im81AmgcsZB9Gfmw=; b=wTGwWiEAOsV83JdHdJQZG5H+D49Y3YRo8Ar6bwz996vj5B9LZ7tVQ0j18AS6V5kl7isewi T9p/kyBVrc9h6EFn4MW9rvzzEq725dENshPlGwDxjhjc5U3i17OIYglvCUxcsmWKVq6FqN xS+vxUjux8vUceonB7vYiXa35FB3o4I= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="qt/sbuA4"; spf=pass (imf21.hostedemail.com: domain of seanjc@google.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660949587; a=rsa-sha256; cv=none; b=Bm0PMejEjWgxiNTuXtO++URqmDNbTAb2oUvcK6g10k+bedIVqr3BHx9RLh2LPgP27W4l2F xOVmMxMolcHFGh6ZCamFTIxc0I5gg5aeawycW4NZRFT9kLu03aMvClcJrosrABlqIVEOc1 +SvK15jaL8QnJA3coIs0VNzcbze/Zd8= Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="qt/sbuA4"; spf=pass (imf21.hostedemail.com: domain of seanjc@google.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EC0C61C00A0 X-Stat-Signature: uiq8jrf13a61gdo837rwcsewxep884fc X-Rspam-User: X-HE-Tag: 1660949587-981103 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 Thu, Aug 18, 2022, Hugh Dickins wrote: > 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: > > > > 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. Ya, sorry, UPM is what we came up with as shorthand for "Unmapping guest Private Memory". Your assumption is spot on, it's just a fancy way of saying "guest is backed with inaccessible fd-based memory". > > 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. The main flaw with KVM providing the fd is that it forces KVM to get into the memory management business, which us KVM folks really, really do not want to do. And based on the types of bugs KVM has had in the past related to memory management, it's a safe bet to say the mm folks don't want us getting involved either :-) The combination of gup()/follow_pte() and mmu_notifiers has worked very well. KVM gets a set of (relatively) simple rules to follow and doesn't have to be taught new things every time a new backing type comes along. And from the other side, KVM has very rarely had to go poke into other subsystems' code to support exposing a new type of memory to guests. What we're trying to do with UPM/fd-based memory is establish a similar contract between mm and KVM, but without requiring mm to also map memory into host userspace. The only way having KVM provide the fd works out in the long run is if KVM is the only subsystem that ever wants to make use of memory that isn't accessible from userspace and isn't tied to a specific backing type, _and_ if the set of backing types that KVM ever supports is kept to an absolute minimum.