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 858F9C83F09 for ; Tue, 8 Jul 2025 18:38:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E95C16B0098; Tue, 8 Jul 2025 14:38:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6D2B6B0099; Tue, 8 Jul 2025 14:38:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D83416B009A; Tue, 8 Jul 2025 14:38:39 -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 C8C376B0098 for ; Tue, 8 Jul 2025 14:38:39 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 62B5E801AB for ; Tue, 8 Jul 2025 18:38:39 +0000 (UTC) X-FDA: 83641958358.01.6792F9F Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf02.hostedemail.com (Postfix) with ESMTP id 93B9880004 for ; Tue, 8 Jul 2025 18:38:37 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="gF5ODk/6"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of tabba@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751999917; 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=SK7lrk7xIi5tD0jrlmCDVWKn5xeGvg9C1giWU24k6Z8=; b=C++U9vkVueMr7jp7+QLLGtUSEZH9BXMYfFKZxfIr+cK18TfBwU1JrLmeGW5tewM4SQW2mh tGmucI0Ky52mTUAvB9ApGju6x1GsIdBD6TwF/XvrizHJF34a8Js0kJpswjvN1SrDoh3nSY znE9uJ10TPn1npVUAEzBDsjmm4F7DKU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="gF5ODk/6"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of tabba@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751999917; a=rsa-sha256; cv=none; b=OpHuGlk2qZrbJpeXMO/ajRpKlgpYhDn3h0gzwvioCHkGkDSo2lIVfCI9ZKsDUleU1jBbQZ kwRmHTZc7YEBbl/PYgaHmPO4J8Dx7nWus22VUbj96xU/GNRZT76t3wNSDRwNMQiHw/8Eon nW2mBS0srCZAmbUqXdy69VdvGYgLW+Y= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4a58197794eso23251cf.1 for ; Tue, 08 Jul 2025 11:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751999917; x=1752604717; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SK7lrk7xIi5tD0jrlmCDVWKn5xeGvg9C1giWU24k6Z8=; b=gF5ODk/6uMZep3KKjhOYLhQfR/1qPv+fW55RoMTxdD9KqNRMPSOAgP+ie5p6iWkvbu NYQVQ57VyD8No9KwbT2D8Xt2hsZ8x6kzdvsr0JNRY7UeKUCD/2vRZbji99cziaaVDZX7 Zyf/qdmoE+jz8HVehodD5I94461I15FIpmdDt72MLWUO8TJYlqpzW217arMNGvS8xTUB 42siO0dMWrlKXAti465tsHTclTqOAblRK+seI0Dng7EC7kdoVWfK2WKHs0Hy2q3eRcSk 8iXHPaTuIu6hkk2UVD0zCDb93jkC72F1hTZuzcMZTCNPNJX8T0Cg5pdXKBfdPsKu7OAg g+Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751999917; x=1752604717; h=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=SK7lrk7xIi5tD0jrlmCDVWKn5xeGvg9C1giWU24k6Z8=; b=wPPHXtMUSaitPiuR1FIgqJK6u0i6z1boHwHUpaOaRLMwIJQyjSveEjXBchsP0THN/d i1kMYe1Hkq0dgf+nZwOsogMzGAZZbz9rLCovnwYRgtp60y2wCUionpzeIxlU0J8y7VPY gQM7N6Mj+LVnomUv/lYqIrxyeTyhC5x1A0ZZUH+u9cAlolkL3s++QKxk2wX6W4ZrW15q 3AHmfhr0bLISsz+qIrbXQetQfzvqAH3TGRXnXknDraS1M18LnX/Kxni7GceKQAJh0JRp X+6Fox6namunJXjkWQYlT3enFhDfM5mY6F3ry4TzoMJ+694T72fZVMnIT0C7pLKRSwJV spzw== X-Forwarded-Encrypted: i=1; AJvYcCW9r5X4WlwF0U0dFZfBH+gZbltnqClCiJzOfXNBJxyBPYK4VGbr9PggNzAyqWtWCh+7XD1YQftP7g==@kvack.org X-Gm-Message-State: AOJu0YyMstwHMKR+3XV+RQPi21hw7jjW1pwIKIKBCTpDRouaDRF7t612 c4V6QMNf2Y1Q07BK1/wWytjrsiv5Jj0EcLXCusp/1qBYmit50CJ9CL9NMvf6uKZYEC86G5+RdPt Um46Ih1C5nFEhbhifv1J8ANh5zyiPIMt817BL8faA X-Gm-Gg: ASbGnctEuXfS98NNAIrXfcA6tgy785jMNRIdUbNxNrp3aiVgb2juDAP6lxrJSBglmnn xlVQLOS3WihQBwbxr+dYMEt3YWA3HahUhJyfTvFjj2sq8DVUsO+jkYaBMKWbWTB9GYSACdp2VO/ 2UdzZzwFJxQrujnnPz/2iXkCOxjkmAJi8G71qE3+fpj/M= X-Google-Smtp-Source: AGHT+IF41f/hEDuNuA09VXbvGPxQNXbKGxA34LGVDDyoOV/7cGhIV3x5DLuwYtaeSPBxKEM3yRLjJM9SZjLNovd7gB4= X-Received: by 2002:a05:622a:5514:b0:4a9:d263:dbc5 with SMTP id d75a77b69052e-4a9dcd2238fmr290521cf.20.1751999916086; Tue, 08 Jul 2025 11:38:36 -0700 (PDT) MIME-Version: 1.0 References: <006899ccedf93f45082390460620753090c01914.camel@intel.com> In-Reply-To: From: Fuad Tabba Date: Tue, 8 Jul 2025 19:37:58 +0100 X-Gm-Features: Ac12FXz2ea5j5gW9dhHxsUTG3z5TMtb4pNBOQU8cekFqn3Ye8zgo2zFcr57HDR8 Message-ID: Subject: Re: [RFC PATCH v2 00/51] 1G page support for guest_memfd To: Sean Christopherson Cc: Vishal Annapurve , Rick P Edgecombe , "pvorel@suse.cz" , "kvm@vger.kernel.org" , "catalin.marinas@arm.com" , Jun Miao , Kirill Shutemov , "pdurrant@amazon.co.uk" , "vbabka@suse.cz" , "peterx@redhat.com" , "x86@kernel.org" , "amoorthy@google.com" , "jack@suse.cz" , "quic_svaddagi@quicinc.com" , "keirf@google.com" , "palmer@dabbelt.com" , "vkuznets@redhat.com" , "mail@maciej.szmigiero.name" , "anthony.yznaga@oracle.com" , Wei W Wang , "Wieczor-Retman, Maciej" , Yan Y Zhao , "ajones@ventanamicro.com" , "willy@infradead.org" , "rppt@kernel.org" , "quic_mnalajal@quicinc.com" , "aik@amd.com" , "usama.arif@bytedance.com" , Dave Hansen , "fvdl@google.com" , "paul.walmsley@sifive.com" , "bfoster@redhat.com" , "nsaenz@amazon.es" , "anup@brainfault.org" , "quic_eberman@quicinc.com" , "linux-kernel@vger.kernel.org" , "thomas.lendacky@amd.com" , "mic@digikod.net" , "oliver.upton@linux.dev" , "akpm@linux-foundation.org" , "quic_cvanscha@quicinc.com" , "steven.price@arm.com" , "binbin.wu@linux.intel.com" , "hughd@google.com" , Zhiquan1 Li , "rientjes@google.com" , "mpe@ellerman.id.au" , Erdem Aktas , "david@redhat.com" , "jgg@ziepe.ca" , "jhubbard@nvidia.com" , Haibo1 Xu , Fan Du , "maz@kernel.org" , "muchun.song@linux.dev" , Isaku Yamahata , "jthoughton@google.com" , "steven.sistare@oracle.com" , "quic_pheragu@quicinc.com" , "jarkko@kernel.org" , "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="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 93B9880004 X-Stat-Signature: shkwmfwchomnqo9f73316pdtt835fejb X-Rspam-User: X-HE-Tag: 1751999917-335494 X-HE-Meta: U2FsdGVkX19teyakIOHehR20cI6/z0dVC+0KecYWEID2R7fU3G9LNeUfdIJg8pMODmzXdXiuU0ta4pO2bQCn86C+vsLlfuZYOWdix5PaDMq54Xn2N2YOKMAyjnBmul4LUZ5fnuwR5gO9gw2tUO2Hmvr2g4G9fkdC4rBPf8swS5bInoSuF/zdBcYmn+YFeZyQELm7pI2mwkh+BRjWQnQEuPgCsiWHEQiIEzTsSgc4twfGrNrpMj/4vZ1EpniPej/HqJE7bepRX68REGsK7HePxftshNU3B8vUGbkYTgCT6PE61p4re71vW/94O2s2LxHSXG5VfB8WyATz7Z4kfdRXadh7aBJdAsGrDDWzFJhPRmnWGA6Fo1NT1swI6yUa5ZNlYksmjvCxgo9VFFwVCbudOdHTZr15DEZFajqm5sJFLyp+NCQMyB4y40z5OPzwg0+gBkWpocQot8uGWorOw/tcgDDh3kBJPw1zydKlCLhNoBopJILHwHmtaiYmpWp47BJ6WRHJL2z6452qoDtldMHld1CtM/TxTSWSJrstjMZYRDYiWbZmhuPDfeQTXqc311ejDqWH/j+6/E5EY/Jon9ed9shIKgL9+DsVR53PJ1mUk/APimquC5QUxW/8cXQASiKsTCa7sAh7CAuzJ0dImu0aq7hTaosAoI2QSVjK8MP3MCcTT81lDcJ1WYUiN879dtdUjO8DhlwFUtGKkMsf2eqWNji0IYDJKcfRcT+K2RVb8ZTjZYXzBvmVV59xMy1jZdh869r5mCLvpQa4fWxupMHMcuZG+cYku1Q0sY3PaOy4QlKqyQukChJSuRVN3Q8C+nKV1DljqEZZK2MglxA0m0+jwAjHIhmxeBf7z9Fn/daNr89rP0mGPxvPVsYiraeH93NQQvm41y081qDkjXcxFe2YOF2Rp7HdwiLqfY4QkMhR2vA8FSIXopYZux5NzIf9DvAmIQo8rILDEKqhUFxVxKQ 9lKoBhAp pexPJuxtaDiOVqEE5Tt/MzUAyLwvl8YgXqTAiL4N+nGFG5Hljc+/S3Yqx/QyNDXvZhaJjqGIiV2VsiU1FZ3+pHcQZLHFuY8bVsed4Px69Y67zYLGyvyrq3jJkfY4gIN2xLXPxOFhcfluBM0+AT4G1lL9GZkOPUeKlVDU6NHtvEbc8oWBLntXmgxaC6f4SPWRNDcfWoO1NzQhPflebNOywSSWYWdN1Rmi5vhlxeCdiBqhEDMyWK56/rGPwKwEBgbaK3kVWmaBbVyBQ+Gq5wFwoQiLTReJulW70TFnvSMr1H3xM1cVQQVg8N7JlYCMIL9sz0envEtFTi5PIEhkx74kBspNZvcNo7scIXTS4iaLroji2UC+xj+axoxMSPA== 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, 8 Jul 2025 at 18:25, Sean Christopherson wrote: > > On Tue, Jul 08, 2025, Fuad Tabba wrote: > > > > I don't think we need a flag to preserve memory as I mentioned in [2]. IIUC, > > > > 1) Conversions are always content-preserving for pKVM. > > > > > > No? Perserving contents on private => shared is a security vulnerability waiting > > > to happen. > > > > Actually it is one of the requirements for pKVM as well as its current > > behavior. We would like to preserve contents both ways, private <=> > > shared, since it is required by some of the potential use cases (e.g., > > guest handling video encoding/decoding). > > > > To make it clear, I'm talking about explicit sharing from the guest, > > not relinquishing memory back to the host. In the case of > > relinquishing (and guest teardown), relinquished memory is poisoned > > (zeroed) in pKVM. > > I forget, what's the "explicit sharing" flow look like? E.g. how/when does pKVM > know it's ok to convert memory from private to shared? I think we'd still want > to make data preservation optional, e.g. to avoid potential leakage with setups > where memory is private by default, but a flag in KVM's uAPI might not be a good > fit since whether or not to preserve data is more of a guest decision (or at least > needs to be ok'd by the guest). In pKVM all sharing and unsharing is triggered by the guest via hypercalls. The host cannot unshare. That said, making data preservation optional works for pKVM and is a good idea, for the reasons that you've mentioned. Cheers, /fuad