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 ABE81C71130 for ; Tue, 8 Jul 2025 00:14:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 357166B03CC; Mon, 7 Jul 2025 20:14:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 300C46B03CD; Mon, 7 Jul 2025 20:14:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EF7C6B03CE; Mon, 7 Jul 2025 20:14:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0FB436B03CC for ; Mon, 7 Jul 2025 20:14:34 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A5E3058E84 for ; Tue, 8 Jul 2025 00:14:33 +0000 (UTC) X-FDA: 83639176026.13.2539329 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf29.hostedemail.com (Postfix) with ESMTP id C5F4D120006 for ; Tue, 8 Jul 2025 00:14:31 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wPjfD5gQ; spf=pass (imf29.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=vannapurve@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=1751933671; 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=Q3YduanZhg5Y0sB2Odh2fAerxegQJGenK+wI+G6lALA=; b=jlVenLNVoF7HmxzXkreWqcjgwsHkIYrC81nP+CQolkD6dFpWPBrWlmKU1Vv2x5Onu4prfG ZGrNX1RVgQ8zH09kEL7UjkYK6jzu1tE+icZN9EyQEI85lcgX3LScKpQBkHiQdp6J+nkqgA RJupuWIfhPN22Mat9/DU1IYl9yiTylg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wPjfD5gQ; spf=pass (imf29.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=vannapurve@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751933671; a=rsa-sha256; cv=none; b=Y0TjpSagwxusXn3v1Iy5ehGBqb/997Ro0RDdbf4Za3yN5MK3Jdf6tRV4UyRitEuYNIHogd 7w4Qv7YjKW6x6Bj8HpAxdF+NFgVnqEfcPxfgZyaZNarrMIacAyzjdxqqIEp2fc8JAkLjAF jm92oaxpFglGyPoxGx5EMy/nUA5wHXg= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-237f270513bso44845ad.1 for ; Mon, 07 Jul 2025 17:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751933671; x=1752538471; 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=Q3YduanZhg5Y0sB2Odh2fAerxegQJGenK+wI+G6lALA=; b=wPjfD5gQiArTQnny/SWz6FOXqfy28w78SFqVp1/LzMbq3QMW3PBlZY0NuesubZr9ON S6uxAV2mV1VirQeNVDwkt3aLDO/hTZ1ZLXUzekiGazoZhsJ95NrZlBiSfZCT8NbXOtTn rITofdOuRcAYgBcyK7g0HspopdPZkqpIm+1cgEXoxwptX0X96rMV4G3HyNY95uJENNX1 5XE1tZaSezy87wF+Y3/43jjNg1vKrsoV8SN9CEkS8g/C877WkqEvSVdjjyxB4+7otlvI h7pplt388UGlD8XiMBLUxZ/bSzWBySomGR9MV9NqVGrEe07TARmU3RUKJN3S2xN5cYNy GFYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751933671; x=1752538471; 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=Q3YduanZhg5Y0sB2Odh2fAerxegQJGenK+wI+G6lALA=; b=lYIQZBtOFTcH/rZUQLHCEIJTTnyNKf5dQqYgNtcH0qAm4/tiTaNteP2mqaJqHhviAp /Z1emYMz9QWbO3K67983R64WUiZhAb7+bzYXmlGtD2UdQzm05NC5T1cgKYEDYT+w8SlA FZg4baujnOnFrNrPW0V62RAXxE+lty6Inc2y8RBD8C5A76wli1Px5BRnN4fNpz8+cTmP ylZqp8oEg/3hBrEEaQy5ywOQDSamTEWBJ+0EqF5QuZTo8/5MkC15FVlFkpe7t5xtFZc/ haLi3R2dPrlClTJcvcH304Kg1N+dNZUbIsVApW2e0KoE2iHnKHZPvgWjZW+Kqdm1UfNY +C9g== X-Forwarded-Encrypted: i=1; AJvYcCW21NMihLKTU8E8IDE5GMRQ0pmrDObhOCuIHvsVGkJLSWBTLpNaM99Xs5Eky+kIGtq3xM8GjSsorg==@kvack.org X-Gm-Message-State: AOJu0YxYCKCcppCpeo6ST1DKqvLFAiqaa0KCRRNLU9Jh1o4up71LHWQM PFHjbb1z0Fdoavmh2p/MUVAz3aIpVMRjFnUfaHcLYYky4QHKUUwzhTKgmxXxk9EweHahpbHH5vo nvQtzcY2GxuF+2Uz6d50dzfj143z8R+UKCArAh/Z2 X-Gm-Gg: ASbGncsKBskK+t+YQlk8pz4u4KWOztRuNrWVtUJRy6kJLBJaIB61hpZVxq1jHf9EdE5 yW6N78ZUMt9koq9YjVte8pUy/KX6DJzDRLOaPibXyheh8+Jp8k1YYTBR/t0WcAswogClFU0iZej sPfKD2l32YWt+i60tD+M0VzlkA/pK9rKDk4/joe7UahgOlXVwEttwjDEYBFi22XN2eHBSUbSYdz Q== X-Google-Smtp-Source: AGHT+IG6uFwfViV4uRKlN7dtoaYWYJ2cAvUBFCR9zSfu99Vwne4/Ojg06Ia/L5ZZcaIijmv3rovYpa5VMqmmYY4ViY8= X-Received: by 2002:a17:903:98c:b0:234:c2e7:a0e7 with SMTP id d9443c01a7336-23dd0f66398mr1276695ad.4.1751933670151; Mon, 07 Jul 2025 17:14:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vishal Annapurve Date: Mon, 7 Jul 2025 17:14:17 -0700 X-Gm-Features: Ac12FXz8PyaRfu4rhO-WaL1IGCmpiHbF9FfbCawryHLn0bG8xOVNVPi0PuKZNZ0 Message-ID: Subject: Re: [RFC PATCH v2 00/51] 1G page support for guest_memfd To: Sean Christopherson Cc: Yan Zhao , Xiaoyao Li , Ackerley Tng , kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-fsdevel@vger.kernel.org, aik@amd.com, ajones@ventanamicro.com, akpm@linux-foundation.org, amoorthy@google.com, anthony.yznaga@oracle.com, anup@brainfault.org, aou@eecs.berkeley.edu, bfoster@redhat.com, binbin.wu@linux.intel.com, brauner@kernel.org, catalin.marinas@arm.com, chao.p.peng@intel.com, chenhuacai@kernel.org, dave.hansen@intel.com, david@redhat.com, dmatlack@google.com, dwmw@amazon.co.uk, erdemaktas@google.com, fan.du@intel.com, fvdl@google.com, graf@amazon.com, haibo1.xu@intel.com, hch@infradead.org, hughd@google.com, ira.weiny@intel.com, isaku.yamahata@intel.com, jack@suse.cz, james.morse@arm.com, jarkko@kernel.org, jgg@ziepe.ca, jgowans@amazon.com, jhubbard@nvidia.com, jroedel@suse.de, jthoughton@google.com, jun.miao@intel.com, kai.huang@intel.com, keirf@google.com, kent.overstreet@linux.dev, kirill.shutemov@intel.com, liam.merwick@oracle.com, maciej.wieczor-retman@intel.com, mail@maciej.szmigiero.name, maz@kernel.org, mic@digikod.net, michael.roth@amd.com, mpe@ellerman.id.au, muchun.song@linux.dev, nikunj@amd.com, nsaenz@amazon.es, oliver.upton@linux.dev, palmer@dabbelt.com, pankaj.gupta@amd.com, paul.walmsley@sifive.com, pbonzini@redhat.com, pdurrant@amazon.co.uk, peterx@redhat.com, pgonda@google.com, pvorel@suse.cz, qperret@google.com, quic_cvanscha@quicinc.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, quic_svaddagi@quicinc.com, quic_tsoni@quicinc.com, richard.weiyang@gmail.com, rick.p.edgecombe@intel.com, rientjes@google.com, roypat@amazon.co.uk, rppt@kernel.org, shuah@kernel.org, steven.price@arm.com, steven.sistare@oracle.com, suzuki.poulose@arm.com, tabba@google.com, thomas.lendacky@amd.com, usama.arif@bytedance.com, vbabka@suse.cz, viro@zeniv.linux.org.uk, vkuznets@redhat.com, wei.w.wang@intel.com, will@kernel.org, willy@infradead.org, yilun.xu@intel.com, yuzenghui@huawei.com, zhiquan1.li@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: C5F4D120006 X-Rspamd-Server: rspam09 X-Stat-Signature: w9shfmdqtirof6tohd6hcccb34jnyuqh X-HE-Tag: 1751933671-542285 X-HE-Meta: U2FsdGVkX18hSZjp3GxOOrpeYCo9i33hG8Lq4y6p6dWi2vQ+XL4ihSKDvpANzadxI5rpUxS8m7Tr2YsV64dY0wd0Y74A04o4/qzgwC5n9l3qhhAeWh00OAjwxyD+KRUI0W8TJ8Hh1pgVBwQAg5J06V7hkisE8L15VZPi3kBHIWH4qh6Gc0GvThcIjl4hB4bpapZIT7rvdxpCVgUx7v0KBUwv265hWMkCXRRq+2x9NTQd+EO4KOBRssAs6TYqItzMxLSed73ntG1R4KWy0Lh/hUnkt2h9TiT4g7aXwaAbO+SlMGyFsnOzM6nGPnM9spxtWRFwPfIso4Ka8MBHr5pAJk7v7MUc9tt2v3N/PDMf7y64Y3qSZLo3AEizMta7xR+oSlfpqcf9+cJCBI50JPzoCtPa/mcUhzsW/lM4AKnH2ehxqhhhzjAkxABZR8pKbGAPNBCRkwCgfbV90c+N0GztVNSHHAwAZTxhnLe2fC4nxCvCvdwCi7JPV9ZZTpgNIWgh/50ffH1f0e+0kgtYFQdxi8IFUaV1gWTHuB/WTCUm6hLpo3xjw3Ry1a7w+LmczdYDVuQWn+OIryLhWcCVmH5JEjqUnwGTcEMeYtATun2M/mOW3f7GiS5aMSzzTw9ipARR57QR+D2eyMn8oAdUzS4XB9l68ZOYQU9KNQnDitqJmoL2dmg2Id5JduZTHgIBu1gexox+6lL4IdIKLWXSVRq0VAP3Gh4RdfZEBTig8L0YVVeH8TpzOVHrJc1CJgeP1b4+UMz+blxGUy5miG8AntaX4lNiC3lY/ZVY3zyASebsxslyAOr31Bui+CYfpWgJnMp9SiU/iXnClr/GKhb5iSlESob+s10n7frtK601ah7aeoRylhkW7+7/saGJYdSAyZqynl2tWrfA7X5FCD9osO8b2Jcrlp2IRxln+AH9qJCTVfbyMLj9WS8l9dJI8c2yA/TLb3RgL5MUGyTdES6vFEV XXaQZ47O zstuzUAb13zs4Y2EqnjNwtfU8FsOuN7s3xLJlNKoN/aHqi74SR5N/ZHgQAdy+kN2d0iNoX0zIv4hQ/N3OSeXOGeKr9RNIUn+L03UH9e+A7BG/R7gHsOMvIPxsOTPW+1CUMxYhnUJsS6VVLdRw1gZp1dv7ZBjoWGPCRC0txDSIqpm/ZNAllQE13wf8T3sGJiYg5ETPJBBaYUl/5+JkmOBljxRSd9TAov70eGbYIjqakjzyrIvq8OG81np7tFOr7CmnArDyURfCb3uVazfS1oza1C+b8h60xvcETtqh9YKfzigT29k= 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 Mon, Jul 7, 2025 at 4:25=E2=80=AFPM Sean Christopherson wrote: > > On Tue, Jul 01, 2025, Vishal Annapurve wrote: > > I would be curious to understand if we need zeroing on conversion for > > Confidential VMs. If not, then the simple rule of zeroing on > > allocation only will work for all usecases. > > Unless I'm misunderstanding what your asking, pKVM very specific does NOT= want > zeroing on conversion, because one of its use cases is in-place conversio= n, e.g. > to fill a shared buffer and then convert it to private so that the buffer= can be > processed in the TEE. Yeah, that makes sense. So "just zero on allocation" (and no more zeroing during conversion) policy will work for pKVM. > > 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/vendo= r 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.