From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 4150E2BD590 for ; Tue, 8 Jul 2025 17:25:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751995518; cv=none; b=Nsg/zj0SPbrncQDt5xUeKE72ErGtwKyWGCrgq1F2BmdHyd4kshAhd3ws7cnwEtNfkimEAZzpxV0c8vH7lL2CTHuV8EZoca8HR8qOzfNTD5On4Hw9Zm3WEafpAag4VBNZjL0nYLli36pBudNXn3rZPAzn33xwdG7huQQl/KtzGYM= 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.201 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-f201.google.com with SMTP id d2e1a72fcca58-74d15d90cdbso1856883b3a.0 for ; Tue, 08 Jul 2025 10:25:17 -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=T+F8/4Y11C9JMMS3GmhSk1lGvUVuWNDBAHcRHwvEKy2q4+WtNq8pmtUx6jrMLIiWJD nPBlWZAK9PnDtlOxAGEyGxK2EE3NMdJ0ZABMjV7Sbe+RUR66OeOXJ13jZz+D8H1I7Tp2 f/MJLfYFBf8O1EydmqNawSuA6JVjy7wXQOdbzq8M1Eynw1GalXzBG2x1fl+JnEPd6QbU 8SQJw66wwmllMtUB/idI3MFac26F8oaz9f8PxNriX08e9Ff48QKHajA3rj3RWv/nf4ss Uq+hBCuonTtRtEyRsImhcUoL/Ob3ejqyKyJD6RZMQR0sLXcEVbIEUZkeUchz7njzhX0L abXQ== X-Forwarded-Encrypted: i=1; AJvYcCUhpHSz5nD9Cz4PKoWs9hduWBPO3XPe4VVdxi+HleIx0EdVJFTmvjUJJvTlaEIGzKacC+yxRXCAebeFxGJo@vger.kernel.org X-Gm-Message-State: AOJu0YzSIh+cSoQOM7zdZFeQWJb0ujGXSqVwsmjU63oYOeSJTXZjk11H rWXDHMLl+NNF48mh529xa1PpVKufeDlEHeUxwtWKlCRux9Nuv/Uc6Y4OTfq52UNZtiM3jmqZz9r 4vfFlmQ== 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: linux-fsdevel@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).