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 0B786C83F10 for ; Thu, 10 Jul 2025 01:30:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 918EF6B0098; Wed, 9 Jul 2025 21:30:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F11B6B009A; Wed, 9 Jul 2025 21:30:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 806816B00B1; Wed, 9 Jul 2025 21:30:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6CFB66B0098 for ; Wed, 9 Jul 2025 21:30:45 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E402058B8F for ; Thu, 10 Jul 2025 01:30:44 +0000 (UTC) X-FDA: 83646625608.12.205BB77 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf14.hostedemail.com (Postfix) with ESMTP id F313C100009 for ; Thu, 10 Jul 2025 01:30:42 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YZckfaj+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=vannapurve@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752111043; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Is04f/Bkm7gJJ/jV1LRjXX51WkiBnOdhDaBr6UaJT6Q=; b=RblUAFzzK7zqY58g5qQRIsK/R/Ho0NmkU/MA4U4GP47hgLOiAglXWPIoJ0NEg5sm0k5fwR rtlMxid9oQ+31nCQdUQIpSL8yK7IdNmDiW9KUZULA8Y5eqRzNcx9xlkkCKcR4sXqwsckZ6 7RYXzuerTKaKwMsbKtckxeBkB80xcAY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752111043; a=rsa-sha256; cv=none; b=MWJHpgovdvLlPW4PpOFAoLQXBfuxs4FbWYJt3omqTF6wP/uqOQEIC5RvBAKXeIZG4QvFLy spvNRiifKZ22gRtk8JYTOCndAW1luIz8/8wZUjk+dOxeWIMQamOBc69V9WFGIsJiikFcTb 3XOwzjDN1pjeqaG8bBxyyux6Q9MW8LY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=YZckfaj+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=vannapurve@google.com Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-237f18108d2so93235ad.0 for ; Wed, 09 Jul 2025 18:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752111042; x=1752715842; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Is04f/Bkm7gJJ/jV1LRjXX51WkiBnOdhDaBr6UaJT6Q=; b=YZckfaj+PMD9n+Vhb6wmfXrP3f3YIe2YI5RGvlp4LQ9qQmbvP6EK/A0ISk8etPEC4t 29Z94gKQSZtOyWkLV/75o0I/uMItmp/edJXNdXl3aMAvusefyOHIfQn6mCxduMdQt2ex cUrwFvcaHvVZFOsli7+wQ4nljp7eqyZw2psSbb0bzuhtTawm1NDU7wOXq4jH/H5cisM9 UgPGY2Pk1rAYc4Ntapr/S8coi/rHYlIcNKZG0IKhiyYylDiYc/KvEPG1YTeoxUfERD4f xAwqyipFgcfuvsyG+I4rAVeTANzLE6QYhyw3LxlXrUmmhqt/tO0+MHCjy0/5N8rg0wT4 Y8dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752111042; x=1752715842; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Is04f/Bkm7gJJ/jV1LRjXX51WkiBnOdhDaBr6UaJT6Q=; b=Omer0Doas2JHhutxItVc73zAuRPm4DoYJoLW1iR3PsjGjlgmVGP1MpdWYpf8Pq6CE5 LbbBz2dPzxZhCEtBh29+2BBn5j7ueKsqo2n115y4YhD2czf8LvI2Scor/VseCPzmAscF Esf1hQTO5/Y0ght8f73JmFIrb3HOtpNcKlB9F4t6BQSkTphpIHYokqP5OFQXErPaG0tE WEjpuJmweSngdTONi+wOkHOMIZMQ2Xm8D61VHxp0gbl4HnQjCwKbHFiXlRWKv1+7QvJs A9NYkPtI2yEGw4xEKlGd6A/80drcDp6C8t6gcOnly5RfqeBmQ/YQq74zeQMfU+tEG8KN wO9w== X-Forwarded-Encrypted: i=1; AJvYcCV6qaNLJnGE2L1YtVP6HcHReB31+QvhYyioD8PZBuE8dSAn8yp1jT/+0/7LCN+LvR1ReUfgN+z2sA==@kvack.org X-Gm-Message-State: AOJu0YwXuWu4jNIcOZSgAEYfc326FiKmjOSvyqC9tfmKvoF+yl+NC16I ER8gwdxXq9MME4DnFLyh1BinUepqvwviCq22z/GPAUdnLtCiDxpMLGoFfaE1aLbwB/ZTjHpZMoL TCA0+2IBsOFOCaC8AZcYIybjk9dutJxHLEIAF3tir X-Gm-Gg: ASbGncv8bvkEKJjZhXyB8pgeUeDj9SAwF2/+YiVDMC1LC8KQQ9a6LYPURXZnbFay88c HKViqLv1LQygtcOYlg1Xt258n4nN2UHZ7FvjNDOBQHbZxZMWelRuug062pdI8GHk3DS0/wNktik +VFPsjWJlZWAs8ove3Yb0R1w9WNwvZtczC43OMmOY5WXRW4ImKgLabPQsdgDG0vFR/HC1T4Mx7b A== X-Google-Smtp-Source: AGHT+IHQRxLhKTVLkbXOo+VEMkswy/Fljlw0yFW5tZ5FbAGr3AvPtN+zX/l8wR12tsrz7uBXDg3nz5YzYaXHlJhS9FA= X-Received: by 2002:a17:903:2350:b0:23c:7be2:59d0 with SMTP id d9443c01a7336-23de43709f4mr1099425ad.23.1752111036578; Wed, 09 Jul 2025 18:30:36 -0700 (PDT) MIME-Version: 1.0 References: <5decd42b3239d665d5e6c5c23e58c16c86488ca8.camel@intel.com> In-Reply-To: From: Vishal Annapurve Date: Wed, 9 Jul 2025 18:30:23 -0700 X-Gm-Features: Ac12FXw12BTQ2UDgvxWfgcVv3vtRLhBXnJJTOmc7eonn3MPXMwv6b46DcRxjVuk Message-ID: Subject: Re: [RFC PATCH v2 00/51] 1G page support for guest_memfd To: Sean Christopherson 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="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: F313C100009 X-Rspamd-Server: rspam03 X-Stat-Signature: 7sng1c51hqpkmsrotbo8j188gop9n9ny X-HE-Tag: 1752111042-195214 X-HE-Meta: U2FsdGVkX1+3o9BDxgkz1LgksKs7TJHvOgYZcayLHmm74HKqKz1Z/OymbrNHCjx5gMdnjObgP/TR2AMAPZSp+ilPZc/tFwnFk+Tp6ek3l4BN//APARsm2tA4cvQV586uTa9XwSvOShAZ3C7G9+F/6/Q7C2YTWfLchkuLDBL6xZmcuWfndwA4ed1epTRghzfWeJN22cCs5L6rEzc4rFhQ/uPm2EdmeENKZ6H/oRqGPMdxjJ0F/O9WyBhAhqkQgffDevNaSXt875DscziNCBH5ybDztkPZyu6O94i3/ybFGg8GZu5IbGamIn+QM/+MZW2KhSnbTNvzHX7E+lvNta8wugXo98jN/cWIU4+AAKCG4zxf14kaMDOoX6DTAFtJCJsI1+gJKxSK2To6WDsseqOjRSm0nbd8eHJcaiuaoedtuW2UDZ6EpRv+6YuR4EczL5c8jNzIsAepQKtMkOCtIrEu8e0z/y1nv/XZ6mbQnGtPZg3Zv0cIEEuVlq5Yk5FiSMxllpQICpOr+EEJz+1J8ei0njYQUaZkFY6x/Rw1odh7Js1AqpemWIu30DuLYhWx/o02IwMOtVZUxP93OY9LEPEde+YoLGBN4/E9SVeKRyJvkhiqUxIBnSZcjm5v8zoup+TCUjP3UuryF+DEr2Dyw9lkiVJAO3RdggBe+uD6ltIpzFP8zjEZ5R8N3OTo53e40rO91NkqaKxQzLvZyaLGhVo1M4yS5TzmKP63XXieqdE7WLlqxasMTTbC+zxwnBCisBRq019jJUgKVnS8cCcPWi/Jb/yxrA793j6Fk5PueW0m99Gk5Nvo0UVyUrlDSP+nWa7JSaFUGOBde6XejRoTI94DGN0XDI3aCNxHB1+7X1HVk8l/NXNT7IPJCHsOR8CtcvyI8qYbZ1gz+reHXoThSF8skHiK98PIbdRLjW7Mz0fEax9WdKopZm9zRlQiANFzC4HV4fBRXc09/k5XCDDrvhw DLD3gFIl ApCHjoTYjWL7qbjAqTbfXszE4bwsUdD1+eKtyZDubz+07MbAc7iYD4iywV32R8iIqcB8nmB16FNRCdfY7Jz+KirjerJ1As9x6iH4GQgOMdoeosVRrZwho1z3aCzkr/QUPdUcteM6GqdRTK2PJeDblKGGVNbSCmgkXK8mXBrPQgDlmrf22TCtelvkj9u02dcNtkZChUm0fBPOyXWTkPGTmEOuk2QhRox7NuaB86S0/TjhNmLakqtagED5fFlBk7AhK3djWmHjbbwsJy7dm0RiZgiCoxqo6sU8YmsWr763nwsSsQFLNZKwp13JyPuO4rtk1675I1q6xF01VNdCLY0mfBesaLxJrwha21XfAKJlVpPCgFEavWWGhDS4oJDLpE2H1cCuefjsbsbYRj6H3cyUbVOCy1WVkdE8ruN9H8D9tVycJsJk= 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 9, 2025 at 8:00=E2=80=AFAM Sean Christopherson wrote: > > 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 t= o define > an ABI that is flexible and robust, but beyond that most of these guideli= nes boil > down to "don't write bad code". My goal for bringing this discussion up is to see if we can better define the role of guest_memfd and how it interacts with other layers, as I see some scenarios that can be improved like kvm_gmem_populate[1] where guest_memfd is trying to fault in pages on behalf of KVM. [1] https://lore.kernel.org/lkml/20250703062641.3247-1-yan.y.zhao@intel.com= / > > > 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 functio= nal > necessity, but guest_memfd exists solely to serve memory to KVM guests, f= ull stop. I look at this as guest_memfd should serve memory to KVM guests and to other users by following some KVM/Arch related guidelines e.g. for CC VMs, guest_memfd can handle certain behavior differently. > > > 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 sho= uld 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. IIUC guest_memfd can only be accessed through the window of memslots and if there are no memslots I don't see the reason for memory still being associated with "virtual machine". Likely because I am yet to completely wrap my head around 'guest_memfd inodes are tied to the Virtual Machine, not to the "struct kvm" instance', I need to spend more time on this one. > > > Some very early thoughts on how guest_memfd could be laid out for the l= ong 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 gues= t_memfd > into the kernel in order to avoid nasty exports and/or ordering dependenc= ies, then > we can do so. But that is 100% an implementation detail and in no way a = design > goal. I agree, this is implementation detail and we need real code to discuss this better.