From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.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 A35B51F91C8 for ; Tue, 8 Jul 2025 17:25:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751995518; cv=none; b=UBQUtTC9LNzCEG/ZaYWKPLVmeTbxEnR2mp+U9WEnHH3G+xw5niXCSwHs3m9OprE3zpGOdwr6+KMD3/A7aWiyhehVQU1SUuK8MfsPlT0SrzB0r0s5qubyoY9eN7+8MRt9NgAJQAm5bHQ73RFSOcc9JAGBZqcKL4gWfSQgXBU0O+s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751995518; c=relaxed/simple; bh=2dpzcIMoo5kncn4prSd58X6gAiB5Ct+J0whAQjT0KUw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=TO9drMOOsLrpfqX4edP0MM1PpdOe/lvbiDrzE+W8H+UtQMgMS8PcMuiZk8aJCx1Xo+xqdjbUbBHz/ElQ0A6SmH6Lwm/XtYHBCYQYkjvIlcyGsSc/tpnsuzR+70d1OSXvJkchfzumgvBeuGrLPiZflHc+loXfW+gnDghj4Lz+hkU= 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=DX4hKLQK; arc=none smtp.client-ip=209.85.210.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="DX4hKLQK" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-74d15d90cdbso1856867b3a.0 for ; Tue, 08 Jul 2025 10:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751995516; x=1752600316; 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=pOwqio/U6duro56etG9g9gjBoY7irnx3UEwaemXddiQ=; b=DX4hKLQKIEGaSUCYwK4P+4Ckx/4lJX7bAZzoAJsXfvHpccsbncYh7E3yMQfoP05Q4M xt1s0i/PNLIfQ6cJknkgk5FHsrv8dfEpMvhrxdLz0tdfjeqWOtnuLhEXpO9Oaem9/zhY K01zT8QxLgDnvP7ycFGeU4KVdVQtCMXPceJoqMwdCJegQEH2X5O9Oirk70iz1xBpG1yI CdHf5AKgpUxVDg2d7gDubXrscCHJLgcJbQEO1v1sKPB5E8EdlSDm7k4uiKq4RF5KUV5r 3+CVq+rcpFX8LpbOoLeEoFq7hQqNEQmxm7hGsJSMtBsDJUJeYUEX1DL/j2eY/6YkmhaA jfVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751995516; x=1752600316; 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=pOwqio/U6duro56etG9g9gjBoY7irnx3UEwaemXddiQ=; b=Ub/rV3Fh4m8QinBleKG8hYt3pnbw+vb21kXiK+mqeDos+KjW0myHhT6ZNOUBy82Jbb K7X2abf29N+F4OI0jWUle5uGQOy1DPGXRevcClYfLHHgdRSiHJKz19T739zNJM+pFf3I w2un6kwMTOO9L41hMcr+d0fqcmEBexPR0yfPGoJUUZPGQ74UDKzWlsWNWlzkw9NymxFb N8cS6fwwYEfPBnMuI8QbrbQ9AW0Ezw06Puk6wujJds6ZxVuQD/PQIREKdV6VPAnW4ZnA eZOyKKCgkrMeIs1V0LSfXRIjnAyhIPW0wEnllSGj4LsJVEV/MHce1hOre+21V24dnqUR DW7g== X-Forwarded-Encrypted: i=1; AJvYcCXJb7rKfeKFqbkOcnHB4R+lTken69hXBrXPwNsNdoBqcMZNqCMwOsLVPYZiqqnWgajv8A4=@vger.kernel.org X-Gm-Message-State: AOJu0YxG7eV0v8Fedv56FojDJx6WSzfYNG1d3cK+X+S8DGzODlKw3gTj pTYCk6hUMRuqsGxq9GyAaMtQk9tlbt/nwNUb92Q3e7gf0z1qE7N0VbAfzoDnq+dGO8/3gWNMAFE s1Z6E1g== X-Google-Smtp-Source: AGHT+IGkRB4yNgSMgfNT0NPmR/wV1gl+lHkhWIKL4jLtjZNROIxI7LYo/8fgTwMpPUWfFv4LNZrzk2dg4WY= X-Received: from pfbei35.prod.google.com ([2002:a05:6a00:80e3:b0:746:2897:67e3]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:b4b:b0:748:68dd:eb8c with SMTP id d2e1a72fcca58-74ce8ad5fd4mr21303958b3a.23.1751995515731; Tue, 08 Jul 2025 10:25:15 -0700 (PDT) Date: Tue, 8 Jul 2025 10:25:14 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: Fuad Tabba 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="us-ascii" 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).