From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D8B52E5421 for ; Wed, 9 Jul 2025 15:00:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752073208; cv=none; b=Xkbz/mZvwlIZl7Y79pDZG5zdcfHsxMGtHZ6JfG2X2vP3jjqLenTvYdEeQQltC876VKbWwxrSnuVZYpZ8ra2d0nWirV1kVWDorSUX8kVuZvRxlTHMhytL2K0CfzLD074nNXp04C5H3La/m/tpbRDFTbm7McIuFpVTvJUHpGyTaW4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752073208; c=relaxed/simple; bh=B9Oiu1rYO7kb4Rbx/R2PzIjG/vjXHDSn58ZvxIx3Eng=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=BpFfgD5A7gd++UoGKJ1IGKRzVh3q92yjWt3PMvkSawi3XhbSxQOoSULbJaW+dZk1qkWbEx7vdUeEuk6L9tfysfWowl5ZpfXK3OrAgZoq51ZYKGBXf/X5dKa/YVXFKAMjiknDXE+EhJpXN3ihPs1lizrEClG1DHkpCdYIv47Y1W4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=MfyKwjx3; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MfyKwjx3" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2356ce66d7cso90333425ad.1 for ; Wed, 09 Jul 2025 08:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752073206; x=1752678006; darn=vger.kernel.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=MfyKwjx3nX24F99iC2py8lcZG7sdzQhK02cBPPcFo7Hso0DPH0GbdpYt+irMdF8l2z NCR0bAGeK2BozuZaO/bAfffrGPfwV4SKXU+/3Oc7RgfxUU/lk6so04f0uE6Noc3DhEpr 9njwESzWnkeWVBrZXvzKpKzyqrOkOLhh3SFY7C17iNzpI+iWHL4VOLT8AKfXS9jQ1F7u mE0Ip19mGChe1OWQAT/adAIbGZolaugq47z+rn9QLtngPRy7Da5UbyJ/8Zv0g+QRwZhQ cklJwMJlgRKVY0dU/JVDh7jV/5thD7xKAZigJF+rpGfO2Ah40u10BihxMhbHu5GW4H6m xmpw== 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=XCFWb4fLsy/6FcRdjz005e4y5YlR9zBagYd87VS6M/lLDxLfJG7ekfZTesZTsIHxrT ktXh8TKfKTKaQQp2xr42raKb4wqkEMMFllf6GwrhY/ozQbTSZKm6CCC5Y+khd8aQVtjk OlQtpKwtqVFKU1jqcx64xJfNsoGg3IKboQXUtbhezz0iyWV1EIemRHtbez2H+mVINPqN Twxt/ck3jd7nMEBPpdaxxGgPjqY/v0qY2/UJqYsUHQtxoxEITVbTSA1v3RhW4AvXxtRC SFPy+9iy5ehekMJzdBuH6o7WKcEqPW6Cd29i+TFP6yyFbzd+El/a0167jcSi02XaFtUB KpoA== X-Forwarded-Encrypted: i=1; AJvYcCWPlVoQko89G9aHq9zKL0re+dKtYOtwdrAx0zZEcWRzpCF1jkBxcp8Q5tT2E1wi13CEPDiE9efkfIn35XI=@vger.kernel.org X-Gm-Message-State: AOJu0Yw8p1YB+wakrH2gLOlmAfYJFXoLiGotcF41QrDwq8R3AHHGYYCz 4DiFZcDr7VCuPCEkvWwAMwfF3zeQRTTQ/0unnAx3gUUM8y22tj2Sno+0+Wf1bufUMUVLvnN/w0y +9YF7WQ== 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: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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" 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.