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 5F00DC83F03 for ; Wed, 9 Jul 2025 15:00:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AF5E6B0088; Wed, 9 Jul 2025 11:00:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 587736B00C4; Wed, 9 Jul 2025 11:00:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49CF06B00C6; Wed, 9 Jul 2025 11:00:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 391206B0088 for ; Wed, 9 Jul 2025 11:00:10 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A7B8C1A01B2 for ; Wed, 9 Jul 2025 15:00:09 +0000 (UTC) X-FDA: 83645036538.18.0781BF5 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf04.hostedemail.com (Postfix) with ESMTP id CBBDB4001D for ; Wed, 9 Jul 2025 15:00:07 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y7qfkF7p; spf=pass (imf04.hostedemail.com: domain of 39YNuaAYKCAIugcpleiqqing.eqonkpwz-oomxcem.qti@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=39YNuaAYKCAIugcpleiqqing.eqonkpwz-oomxcem.qti@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752073207; 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=EgTnAwf0t/6F9APa2rh1DyKxauhomMCkahh2HJItwX0=; b=X2S4JxRq5OUVc/8xjqQI1DSPNtoIhhydqYNNKvFj2J1rpps38/+OuEVtIQNBbElhQUuq4l DGWxiNaQXUprrX0Av3IfQLxAQ9b+bQoApfihPSm9amNRBLxjo6ogwE6o61dQhrDfM6tBGc HJBxYhGNkFwW0Dccj/5erNCsGt2dxXI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y7qfkF7p; spf=pass (imf04.hostedemail.com: domain of 39YNuaAYKCAIugcpleiqqing.eqonkpwz-oomxcem.qti@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=39YNuaAYKCAIugcpleiqqing.eqonkpwz-oomxcem.qti@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752073207; a=rsa-sha256; cv=none; b=P4mz3qNBIn7QtqCvzmsjPSg5JNpS8nnXodUwqUod6qcu5lDkB5rQf2Jzf7HhZLL3jHUneI tTw+39WTq+2FCZRM+wVhRBBuqA1n3mnvLwbDGLyNmIHc0bSb0AqtFW1r18Fv4m5fb2+M9A OL3rzjPn/ymaG0dt2krvtorVwHI47PU= Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-23536f7c2d7so88246085ad.2 for ; Wed, 09 Jul 2025 08:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752073206; x=1752678006; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=EgTnAwf0t/6F9APa2rh1DyKxauhomMCkahh2HJItwX0=; b=Y7qfkF7p7ImcW36IcQEytm6ncqpedRGRdGnuKGoi7yxTEze8DAfBFJydXJt1KbPxqx bUEp72G1Njau2L0En2D1bTOVQjFoRaGekDerLiXJg6IVoPLlbPpgonfbIIjm5ZfElNRr OF13ewxdRWV/4LxUnGcbv4jbWHGLjHPujCB0f03xSaLIFANIRUDgdR4wtXyuNH78n6Bu /H5Lp/0cO7WjjPtf6CpysCcFOKk4TduPojVbsr+lPYH2ETWBZltVY++YJOzNUKXGOgg0 1iTGKjKVEB7JfJLDQeL1t1sFzLknT1UnUJ4u5C7pqXA1hXSugW7bjv1v00S1haP9DTNn mAzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752073206; x=1752678006; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EgTnAwf0t/6F9APa2rh1DyKxauhomMCkahh2HJItwX0=; b=baW5g42h9KxM52vCzwnSEx2NBOdwoNf8B+l2trodX0fIUzXDsp6+NlcNskFP9+44CZ zG11p5KPYBtH8kjsSAP93h1Wisto4MQSUarotleeqt8EK8Rjz41F4c4G5hLW953r0L+3 RuK+yRE94npGdEarxYO4W+y2XUpeAkdfjxwgJREVGwF3z+Wq7EHtod4LzTwqNS10/Udd 2s1ya+C8/oA1HKOFY/7Z0dt/QbP9CG76rgankKyVgb68Lq3AUmowIP3USX8aPMrVIs/k wmrxQKViKDtoQ51wUcf/nEKmkesqi2xFQCPU4UiY3trog7/cLLTsZZkq4mvTdMzz66Ii AIlg== X-Forwarded-Encrypted: i=1; AJvYcCWLBcI79Pz9qmMCNOYhU2J0V5v97j4lFbbMT2oyCZcmtcu5brsE1gvlVlFdAlnPMv/Pt7TZakOBew==@kvack.org X-Gm-Message-State: AOJu0YxgTUdDAmc/571PUtrK9hLQZx3Tsaosmmw9uEfYcvycTmU/KkxB 4yDJhmTh5EP79NLVZIBqpib8Y3P41+qF7p8zuKuSkNQjssTM6DKTHNduAG4BntwI0zTYDeGq0Rj kjX7SQw== X-Google-Smtp-Source: AGHT+IGIxCNWDvTXdGWXukQOWTlHDKHcqKhvDakCv68J774ZGhWIyAsbzsp2bcmyGLtmMTkKs6eBKiZcgtc= X-Received: from plvv2.prod.google.com ([2002:a17:902:d082:b0:234:3f28:4851]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:2f87:b0:235:e96b:191c with SMTP id d9443c01a7336-23ddb34fa56mr52368805ad.29.1752073205780; Wed, 09 Jul 2025 08:00:05 -0700 (PDT) Date: Wed, 9 Jul 2025 08:00:04 -0700 In-Reply-To: Mime-Version: 1.0 References: <5decd42b3239d665d5e6c5c23e58c16c86488ca8.camel@intel.com> Message-ID: Subject: Re: [RFC PATCH v2 00/51] 1G page support for guest_memfd From: Sean Christopherson To: Vishal Annapurve Cc: Rick P Edgecombe , "pvorel@suse.cz" , "kvm@vger.kernel.org" , "catalin.marinas@arm.com" , Jun Miao , "palmer@dabbelt.com" , "pdurrant@amazon.co.uk" , "vbabka@suse.cz" , "peterx@redhat.com" , "x86@kernel.org" , "amoorthy@google.com" , "tabba@google.com" , "quic_svaddagi@quicinc.com" , "maz@kernel.org" , "vkuznets@redhat.com" , "anthony.yznaga@oracle.com" , "mail@maciej.szmigiero.name" , "quic_eberman@quicinc.com" , Wei W Wang , Fan Du , "Wieczor-Retman, Maciej" , Yan Y Zhao , "ajones@ventanamicro.com" , Dave Hansen , "paul.walmsley@sifive.com" , "quic_mnalajal@quicinc.com" , "aik@amd.com" , "usama.arif@bytedance.com" , "fvdl@google.com" , "jack@suse.cz" , "quic_cvanscha@quicinc.com" , Kirill Shutemov , "willy@infradead.org" , "steven.price@arm.com" , "anup@brainfault.org" , "thomas.lendacky@amd.com" , "keirf@google.com" , "mic@digikod.net" , "linux-kernel@vger.kernel.org" , "nsaenz@amazon.es" , "akpm@linux-foundation.org" , "oliver.upton@linux.dev" , "binbin.wu@linux.intel.com" , "muchun.song@linux.dev" , Zhiquan1 Li , "rientjes@google.com" , Erdem Aktas , "mpe@ellerman.id.au" , "david@redhat.com" , "jgg@ziepe.ca" , "hughd@google.com" , "jhubbard@nvidia.com" , Haibo1 Xu , Isaku Yamahata , "jthoughton@google.com" , "rppt@kernel.org" , "steven.sistare@oracle.com" , "jarkko@kernel.org" , "quic_pheragu@quicinc.com" , "chenhuacai@kernel.org" , Kai Huang , "shuah@kernel.org" , "bfoster@redhat.com" , "dwmw@amazon.co.uk" , Chao P Peng , "pankaj.gupta@amd.com" , Alexander Graf , "nikunj@amd.com" , "viro@zeniv.linux.org.uk" , "pbonzini@redhat.com" , "yuzenghui@huawei.com" , "jroedel@suse.de" , "suzuki.poulose@arm.com" , "jgowans@amazon.com" , Yilun Xu , "liam.merwick@oracle.com" , "michael.roth@amd.com" , "quic_tsoni@quicinc.com" , Xiaoyao Li , "aou@eecs.berkeley.edu" , Ira Weiny , "richard.weiyang@gmail.com" , "kent.overstreet@linux.dev" , "qperret@google.com" , "dmatlack@google.com" , "james.morse@arm.com" , "brauner@kernel.org" , "linux-fsdevel@vger.kernel.org" , "ackerleytng@google.com" , "pgonda@google.com" , "quic_pderrin@quicinc.com" , "roypat@amazon.co.uk" , "hch@infradead.org" , "will@kernel.org" , "linux-mm@kvack.org" Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: CBBDB4001D X-Stat-Signature: ee5ofdwg88r5gz4z15qyjqnjarxw1amo X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1752073207-208530 X-HE-Meta: U2FsdGVkX18BxpmlGbRbCkzvhw9TOvGDhF7+HWi7OpwGD/g7wuwI5eYjD8YZukcrpzXh0dAgcoNtmCf93x/7dtRnwNE7APBSaQO0liwh8HK7+K5c/OgaSC33Mo+N8isBFxjXd/Rg4c9wdgq9/gL7Cn5m+lXtd8xHa0ExE01x7yWQs8jV+T54J2fkfGkEAzlrlc5Qf+za5pCzsGgmfzfP4/qL7IuKAyFM0TwaZEllzV7bj4QVSWFTElfQFvtPgjYiM8TVoUrKqLXlM8CbjELywVOUxeRBPFuYq9lA8JeJNdaipwRLSBuEZm/iorlwVaIJXwqLpTz0TArdvysA4IkVgTGqUpWSqsS6ABSNST2EnIdiQPrGEBuvPVryObs+Z0O3uoRzKAJLSEpymDg818zpsxvR9hhiZkuBShqx9vAi4HERWYxl+Z9lws89BkIKJHswRV5b2FJClWm1uMK1sEy4SHVz56u28jiI3MXzwaElVC2k13KPXt9LWqCIXt0XjVCs30lmDYuBzhbNr+wkIFRDuFE8jEhl8TqK2O1Xntj7CWqSJIaEK+zWMl4vV9Zcy7/C3eBYk0mEN8IET1JccTyAs+VqR+VYg8mu+etCB5RCP7FeKPR7Xqh/lwL75+B0LbgV+tCN9CZ/gSOZ+t1f5x/CoyntYSqF4GZ8n3bCB9fP+/dHQAjbKTit0TAja5HBVokxIXCgw+Y5koa2Q8ZN6FSwpp7Lp53gOd+G7/85eM3gqHDxOxbZWaaS7fess9+8F22FxSvVsUO/mJX3Q3LxrfTdVTTO/aJIw4Ke9h1w9u96ETM+BK2eZLwJTh8bG9XATJdR/P7YyfVKTa/fb358ijR0NkiKgIS2jC/24vY5D28xoDJ4E0cW6SjGUpK+VezY0Z+Hnv2xH6awH17trp7i9LFXazqGDlyWeQiuaEcKMw7Ji5hresxiZ8XQEMFH5zVSpWQHFAXr61Y2Ek4YhR1sIoD P3NoJQQv GeNMC+Tqk8GNiMx8X5dh5O8BoKl5A0NKXs2e0Mzz2QeKZo33p1DHfMRN6qsWZWAb/wskp0nXvG9Qv6D5pyj12mTKJA0f9hG+1CxP9FH5K7rcXh4dIK+KWKsjQhURqrInhSr5PxvEbtzayeLm8CJp3vCOhIp38+sIir6ne7AujlKIk1i9M96fFhvqPnmLE5JuL5Ua4++xcdWOSrkJU1SLvDSDj2rAVCqKyWeMNms2W7h7CigN7+PLzEYh7fEDZaNAU4nuXU2RszrtunibuByM9HGQ9dXYwkZSu77WuITIoIzZRK72smrRnzZJkiy/Bioxbid2Hth63DTPRzwTUI7NI3uCx/XGoNW+xvFg+sttQXJlXMrYTIyIr3TKHF9KVevzieScCxkwNmpJWQw3qaj6VRmBRONYfSrxO8M59u41wZxsxuo6ew6OCqkMo7WIeFRIMFGJ8Nv9OY9qK3ciAWO3nyVGT3mrEWXnKF5JRvWRRkICWSAg4sEtvNJV2Mh23veklRhWNUDJoJERkuiW1TER9R7VvAXBH2OvRHBQI4729Bu6fHIi2P61CAm0FiFpQbQFQS1mhkUqAa+bCW4BTOvXjpO3ULi9WH3uL4bidHzCS+VqqZcfFnt9HouTxQDn8/6NETowJaULSmvSb8tcJMCFlJo/6c+0zBgAH/L3v2BPbtnqzpcDEAjrT79jTV4dwMn2CAbrEfElWS9Wwd9xeLYIb6dEIrI1d+efu/Xl3ROG6KqV57KJh8YQmeAjyaw== 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: List-Subscribe: List-Unsubscribe: On Wed, Jul 09, 2025, Vishal Annapurve wrote: > I think we can simplify the role of guest_memfd in line with discussion [1]: I genuinely don't understand what you're trying to "simplify". We need to define an ABI that is flexible and robust, but beyond that most of these guidelines boil down to "don't write bad code". > 1) guest_memfd is a memory provider for userspace, KVM, IOMMU. No, guest_memfd is a memory provider for KVM guests. That memory *might* be mapped by userspace and/or into IOMMU page tables in order out of functional necessity, but guest_memfd exists solely to serve memory to KVM guests, full stop. > 3) KVM should ideally associate the lifetime of backing > pagetables/protection tables/RMP tables with the lifetime of the > binding of memslots with guest_memfd. Again, please align your indentation. > - Today KVM SNP logic ties RMP table entry lifetimes with how > long the folios are mapped in guest_memfd, which I think should be > revisited. Why? Memslots are ephemeral per-"struct kvm" mappings. RMP entries and guest_memfd inodes are tied to the Virtual Machine, not to the "struct kvm" instance. > Some very early thoughts on how guest_memfd could be laid out for the long term: > 1) guest_memfd code ideally should be built-in to the kernel. Why? How is this at all relevant? If we need to bake some parts of guest_memfd into the kernel in order to avoid nasty exports and/or ordering dependencies, then we can do so. But that is 100% an implementation detail and in no way a design goal.