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 1D1D1C8303C for ; Tue, 8 Jul 2025 14:20:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B56D06B0306; Tue, 8 Jul 2025 10:20:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2F286B0307; Tue, 8 Jul 2025 10:20:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A44766B0308; Tue, 8 Jul 2025 10:20:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 91D2F6B0306 for ; Tue, 8 Jul 2025 10:20:43 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4DC10C064A for ; Tue, 8 Jul 2025 14:20:43 +0000 (UTC) X-FDA: 83641308366.13.4EC7222 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf28.hostedemail.com (Postfix) with ESMTP id B240AC000F for ; Tue, 8 Jul 2025 14:20:41 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LGdJwKyV; spf=pass (imf28.hostedemail.com: domain of 3NyltaAYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3NyltaAYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@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=1751984441; 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=YEjiVQlfJLOP7kVxMpQDdQ/vGMM3KscEJ6hcSffOpCY=; b=dT//h4J0V5w43R6jQQ/eyGJPf0lLyFktev6oH2Wm6h2UBWxHgJeMQMEUuryMF1xGrTvfQV ncGesSKSp+sm241R87CSwSGU5ql3zYoBhHGujfG+EXatMwwr31SQrY3mAPD+Z1WW37ge0f Zx0WuZclGWlVtpRmVfwb8ZWfTzTJztw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LGdJwKyV; spf=pass (imf28.hostedemail.com: domain of 3NyltaAYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3NyltaAYKCIg4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751984441; a=rsa-sha256; cv=none; b=49OBV5E79bLXhAUL89BpYy0lLLNN1kF4BeP2cFRvd7IaMlV8jXzqpcIfsBfMreZ0rGm9YB qsfDT1vY9C4RaIOxt0Qf4V8mRr24Ev/RLRYcgOeCLdvwel39oNjWbBTyQB+tSL5PpzhqW2 eksDo5Zt6Zz6WVkmslm9OTttmI34mzY= Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-23507382e64so38961145ad.2 for ; Tue, 08 Jul 2025 07:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751984440; x=1752589240; 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=YEjiVQlfJLOP7kVxMpQDdQ/vGMM3KscEJ6hcSffOpCY=; b=LGdJwKyVhLhG1/gyLncm7rBCV4z2h/EXmXZET0HCP/D/hulpz6YgxuPDdURabUlQLT 4gefNe27nT3xItUz7zKwbhwV1EeILVc1wPmIEW6YMgl1xsq8PbyRQHMxS/EKLvC9iDj3 X0/X5eFXsvFE22WQ42wqAgfGQUEARZhHbRKKuRqqGyRACLlnu7Agikz2AnwRNho6boUx MV8fk+WgOvKJrdC4AFd//LuNSTcHMjLoobIt5OPQlgZsiqHcLWJE5s1rFlqLaqmEgkdv 5MB1Jq3puN2ryPnAwalrTPH+KIanbAvHJh2Pw+R5Ef8bQmy+/jWLm8PGQXOUXu5IKfcU YC3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751984440; x=1752589240; 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=YEjiVQlfJLOP7kVxMpQDdQ/vGMM3KscEJ6hcSffOpCY=; b=O/aB9Gxt0wzsSgpuj1G88BMfKsnStM70A8kwK7GUpXf7bt8IDGXVUioBXaNuorb1un d8LlrDwWYKcbfsQ/62NM9kolpXwdwjzocI2FSrl7pyb0W/SeOc+3PPloRGBtdB2fTga7 8VGpa3WMeYGEFjyZl1LsRQJoLhTECH8nfkECapkg+TxbiTATT3s4YHsmDX6D7hb3VC3E aaJo0upMTQWYIjaFlMz7alMkrGdHjvSWeNAjzB2mYGMWpzdfMm5FHp7oA9pD2UFwMPQw NUOyTHmtVztkwbQ6PjSOn2c8ZhuRLfdDAFy8OwvcAvH1hWi8K1Xy0zatYlK7AvXBKWaG 6VMw== X-Forwarded-Encrypted: i=1; AJvYcCWr/kkvuq4K+nrM2jlxQ8nWDSAs840yXs39XLmFbky0slVYUiyP16lil4b1lY7yCdjM1n4Ptxb1XQ==@kvack.org X-Gm-Message-State: AOJu0YzM+URle9keNp/LZn95ipWo5LRnTyGoH2vjEUkjfdrb5Az5bpsz Jf72JKSYG0GWSaMvpaRdO0TO5+aYP3XWzxYWPwhVKN2OsVBVbOIagQxyPVRMPMS/kRu5R9aZFn+ CZxwpsQ== X-Google-Smtp-Source: AGHT+IHzXNaPQBczSLUZ2cM9qmp+nPh8k2XVabSQDtWv0v/y5gyBaS/+ETp76jHwOBS4DHAguPnj+YOZVZk= X-Received: from pjyd4.prod.google.com ([2002:a17:90a:dfc4:b0:312:f31a:af55]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:d48f:b0:235:7c6:ebdb with SMTP id d9443c01a7336-23c8746532fmr277306715ad.10.1751984439683; Tue, 08 Jul 2025 07:20:39 -0700 (PDT) Date: Tue, 8 Jul 2025 07:20:38 -0700 In-Reply-To: <006899ccedf93f45082390460620753090c01914.camel@intel.com> Mime-Version: 1.0 References: <006899ccedf93f45082390460620753090c01914.camel@intel.com> Message-ID: Subject: Re: [RFC PATCH v2 00/51] 1G page support for guest_memfd From: Sean Christopherson To: Rick P Edgecombe Cc: Vishal Annapurve , "palmer@dabbelt.com" , "kvm@vger.kernel.org" , "catalin.marinas@arm.com" , Jun Miao , "nsaenz@amazon.es" , Kirill Shutemov , "pdurrant@amazon.co.uk" , "peterx@redhat.com" , "x86@kernel.org" , "amoorthy@google.com" , "jack@suse.cz" , "maz@kernel.org" , "keirf@google.com" , "pvorel@suse.cz" , "anthony.yznaga@oracle.com" , "mail@maciej.szmigiero.name" , "hughd@google.com" , "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" , "steven.price@arm.com" , "vkuznets@redhat.com" , "fvdl@google.com" , "rppt@kernel.org" , "bfoster@redhat.com" , "quic_cvanscha@quicinc.com" , "vbabka@suse.cz" , "anup@brainfault.org" , "linux-kernel@vger.kernel.org" , "tabba@google.com" , "mic@digikod.net" , "oliver.upton@linux.dev" , "akpm@linux-foundation.org" , "usama.arif@bytedance.com" , "thomas.lendacky@amd.com" , "muchun.song@linux.dev" , "binbin.wu@linux.intel.com" , Zhiquan1 Li , "rientjes@google.com" , Erdem Aktas , "mpe@ellerman.id.au" , "david@redhat.com" , "jgg@ziepe.ca" , "willy@infradead.org" , Haibo1 Xu , "jhubbard@nvidia.com" , "quic_svaddagi@quicinc.com" , Isaku Yamahata , "jthoughton@google.com" , "steven.sistare@oracle.com" , "jarkko@kernel.org" , "quic_pheragu@quicinc.com" , "chenhuacai@kernel.org" , Kai Huang , "shuah@kernel.org" , "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" , "hch@infradead.org" , "linux-mm@kvack.org" , "will@kernel.org" , "roypat@amazon.co.uk" Content-Type: text/plain; charset="us-ascii" X-Stat-Signature: eux6xstodkmqozuyads6tuoqiakraagz X-Rspamd-Queue-Id: B240AC000F X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751984441-63170 X-HE-Meta: U2FsdGVkX1/zIhl4K0BXLNbwPlNLy1mKrHwRx6i6aVsgCXbkdzP7fB11Dso5n8HmNREbac8VC3ei3Gmcetzauo+Y3VD4SjmRB5cBJLYzV73TpiqtN1dYAtqLn7qKJ07WmvLSdYj/w1TORx5FvBYSwPyp1OoO07e/MiskZXMq5txyxiXHMTl91iSkRdJF5GkwoaOUvPG3JoK6SLAZmVwBY4A3j3xJTiNnVPoSaIPSlPq57GpHzy6JkO2bfMzRjBIgWsdu3vnkNhSxdoc1ijKVHI9icedGmkZCkiLQFWRQjM2kOfJK72OAxI8bQSjaPXdSmaxAWfuWZqxCH5UEdWNETV4cfQFmZgHKKx9aYbItxWIJ3p3nwTTVGbgU6R30I779WLbeGvNtrGY+M6GwtGQOSC/dVvCYZQ4Ta4saQLYLYWFFm02dvd1Z+G8miI3tI4sn1HQ/jLjyzsrv4tNL4JQj9xFcRNx17j+8PlgPn0M+BfDMcAsmiO6r2mkN/jsQl0ZwbiZOYJ+FmSInd5qUk3owag7Ilg5hkWaYb5EqvaC/1v2FkbJG7/73D5k46MvJQ6ucEGRZjiWGRtfolCtxptYqYOuG83slu6tWyNceHKj+CVgXyO3vmHR0kMMkOWT5QfCj5FcgzzzLelEgSw+5hXc8EylKyQU8bVFih/aXsiKYD4nIh3xrPYL//d4Bsp/JGlldRH90re+HcaYVSlzciY/sxBORz9RSSXf/nRAI7lbZ0KUlLt831MYNLOutDzvYa8JabblrNrMqSx8rElljWv8TSOAtDfNYt89t65cEClQRa529dcmnRxPTWBI6MP7ZJv/1xsdLD4BLGA1SA9AcQDVouzAGHGwui4IJOxwm8gpU1ag5u9Y7BOFKaee/pBLuoOVnnAdrScFILecdzd0PhOWM5TMc63leUtLU8Z/iWXt6Khf3QL0kOCpPShpqFFjzD7inoqgDHQWZwjm9bSLPZ7e eV646xPd P9iEuzwe8UOOEShuknV3Ij4bKXdCn8cx80N91eAdOgbv6PAMCDUWrM0mgGOWWzTK13VPYVujR9BWaz2mNDnIanjcpQRDg6rPvJrVZnXc1viobf/ueuQZa+FLoY1JA48zERRoBcKW2Zf4gKfG4Mrrzpg7IGlyBEJLMyorsNVQUhzWAGnshBvSfQtZFv9ai9Kb+XD/CjU0S5R4tH5EKobDjwvu6fCH2Vt41n0L/xCJrk77F9rLyC4XWUyPwl+1CfdX+UDDZoaqWn+Cl77wFHRAFkQ9elg+5lY/rCd8WaP3qee0E09J5sWhuqekYKhg2uq1xyWbMHi1QHvtNDonutVxMU7PVihg4uzKUDhYSQxzE0Aoe0psKeGsrN+nsgEW2N1b+PIexZW9uKP8T16mJwR6ugeNolFE6QqO9OVPwP3/d+Gryt4HVTbBemkJ/biMd9ia/qInQ 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 Tue, Jul 08, 2025, Rick P Edgecombe wrote: > On Mon, 2025-07-07 at 17:14 -0700, Vishal Annapurve wrote: > > > > > > Some architectures, e.g. SNP and TDX, may effectively require zeroing on > > > conversion, > > > but that's essentially a property of the architecture, i.e. an arch/vendor > > > specific > > > detail. > > > > Conversion operation is a unique capability supported by guest_memfd > > files so my intention of bringing up zeroing was to better understand > > the need and clarify the role of guest_memfd in handling zeroing > > during conversion. > > > > Not sure if I am misinterpreting you, but treating "zeroing during > > conversion" as the responsibility of arch/vendor specific > > implementation outside of guest_memfd sounds good to me. > > For TDX if we don't zero on conversion from private->shared we will be dependent > on behavior of the CPU when reading memory with keyid 0, which was previously > encrypted and has some protection bits set. I don't *think* the behavior is > architectural. So it might be prudent to either make it so, or zero it in the > kernel in order to not make non-architectual behavior into userspace ABI. Ya, by "vendor specific", I was also lumping in cases where the kernel would need to zero memory in order to not end up with effectively undefined behavior. > Up the thread Vishal says we need to support operations that use in-place > conversion (overloaded term now I think, btw). Why exactly is pKVM using > private/shared conversion for this private data provisioning? Because it's literally converting memory from shared to private? And IICU, it's not a one-time provisioning, e.g. memory can go: shared => fill => private => consume => shared => fill => private => consume > Instead of a special provisioning operation like the others? (Xiaoyao's > suggestion) Are you referring to this suggestion? : And maybe a new flag for KVM_GMEM_CONVERT_PRIVATE for user space to : explicitly request that the page range is converted to private and the : content needs to be retained. So that TDX can identify which case needs : to call in-place TDH.PAGE.ADD. If so, I agree with that idea, e.g. add a PRESERVE flag or whatever. That way userspace has explicit control over what happens to the data during conversion, and KVM can reject unsupported conversions, e.g. PRESERVE is only allowed for shared => private and only for select VM types.