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 81809C83F09 for ; Tue, 8 Jul 2025 17:25:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2732E6B0098; Tue, 8 Jul 2025 13:25:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 223CE6B0099; Tue, 8 Jul 2025 13:25:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 112E46B009A; Tue, 8 Jul 2025 13:25:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0008F6B0098 for ; Tue, 8 Jul 2025 13:25:19 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 565C6160153 for ; Tue, 8 Jul 2025 17:25:19 +0000 (UTC) X-FDA: 83641773558.27.ABA4CDD Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) by imf02.hostedemail.com (Postfix) with ESMTP id ADBD680004 for ; Tue, 8 Jul 2025 17:25:17 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3xS22jUJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of 3e1RtaAYKCCQSEANJCGOOGLE.COMLINUX-MMKVACK.ORG@flex--seanjc.bounces.google.com designates 209.85.210.202 as permitted sender) smtp.mailfrom=3e1RtaAYKCCQSEANJCGOOGLE.COMLINUX-MMKVACK.ORG@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751995517; a=rsa-sha256; cv=none; b=yEKck5+B69Tm83XYsIYKKm4ELRwYJmV6nseHvS2zPzlHj9XOq1fcm5bX8dLnM2Nw3Y3Ooi lq4cySH5api5TCYkf0CmWxLXKlXyJOCMJE0MGn8p8Fogl8nhhmpMFbO4zlVPE5VSLZXTnB fJ1o6UAcfnrciHeMw0HyzLfRMlb7YWo= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3xS22jUJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of 3e1RtaAYKCCQSEANJCGOOGLE.COMLINUX-MMKVACK.ORG@flex--seanjc.bounces.google.com designates 209.85.210.202 as permitted sender) smtp.mailfrom=3e1RtaAYKCCQSEANJCGOOGLE.COMLINUX-MMKVACK.ORG@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751995517; 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=pOwqio/U6duro56etG9g9gjBoY7irnx3UEwaemXddiQ=; b=RCc9OFMnZ0VLf8MKg4G1eF3e7Q0HbwZ07hsbMk4gS4iXTPxCkFs7P1yrtNWryb8LFUvf2g rWwd+PSVBbWBWoiUk+IGOrX3vfWBAnDYsAfzsRShUTKwyiTyJyUsstB0GkzcvpFLiATgr3 6WSXMIE/pv5waqa+bp+B2oY4ztqimis= Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-748f13ef248so4049761b3a.3 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=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=pOwqio/U6duro56etG9g9gjBoY7irnx3UEwaemXddiQ=; b=3xS22jUJmO+bHa7D5DTwRb4JuqzWaSe/NhteBEvTY7k52HhLygcEVDbNaWvEiFbggB 1bMqLsjJw+n9GsK2Ts9Hd78yYpJ7J/DXzl9UNas2/ysCyZ5LHOZmmaMtpCIKNVg4kXwF 2+eljKBlRzDeBjiwtQ7b+yICV6kosS8uZdhYYzrDeDFIq2YBib0AZ+QQ1uw7mgRWhwXK 21YsSPzOmbhPmfBkd/N8AZRP94bPzELd9RxrAzLRw88F4Ha3GfWSK76+sVmWljALSjZO qA5JasMc/5fEwykjCj7pxWoYagag/XSHD96u9TQKOghnCmDQOK6PD5/4SxoKO5XWjopP MDkA== 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=kU1yKxRA6CJsr7oJkLBHbMEr0V2yWki2v/zuqo8m185hgsCxoNHuay+3LJsUmApFTr sUbfDe5+WIb0EQA8tHIZOR1AFUkbV4utlK4MMdspheRbbdTI7hrSwUl5VHHf/MW+5TjF qg4rJ2CXImCAyW41/VOqNh4TLeUmaEi+Ejg+RsGXzjh+73DbXyHRDCOSS6valACdFUGc /tk6s0pFM2g0/fkA3CWS9TX+/zblfZAlidCfA/NEUErh2qsAIeUOFD7CUHxtMTFXJh/O caQ+2h9jXKjhIv0Ctedbhs252OmA+Z+qe+yqYK0aYcuZnjtqMfvWBbsU72n7LPpvBpEs jj+Q== X-Forwarded-Encrypted: i=1; AJvYcCWr/8Wob6zgksJ4uNkERZI9HzJbcv/IJrExq2A3qbdydkf9I5u99povLWY8t0Da8a3iJtMrz2rVVA==@kvack.org X-Gm-Message-State: AOJu0YxqMg2dcor0Cn+NGiqKWyVemlV2qhsPQQKqV3CG7moeqD2n3PFa fm82Ma9v8qwPF0NnInQ+6tR4Uyo/CpNgli7+TA9fmq3J7gBrE46g7c8NLQ/FE2iDWP4kc+VO9p8 kZaZ95A== 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: 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" X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: ADBD680004 X-Stat-Signature: 7iryjn31nwmbq8tja95g9p1cdfcc4uwu X-HE-Tag: 1751995517-96968 X-HE-Meta: U2FsdGVkX19CFLIPBdIeOhwPlnKqwUtPDNdqFICHP7yw1QRiX6CeaeSZDJfKUeBIl8UvaF22+kmmpjy3mS5FOEnno2WvJ+V92Y0tN0P6nLhaeWYQwG8Q+zOkfLF+ZYhP2qGloc0ECLQ67YpqCbsSY/VhnmUQ3Ru5wr2ixT7zGnauwvWAV9MmkzJMB2xdVwPP2Cp5H/gfeZb3EX3ZaXEtKcPBoozry2vWBQU23A/twQQqCKXMZT1iR3Kgu6HDylycprBAU41k6DRY+55UDjVU+JoUYSxcqeUoonwLuzf7Jgt0FEPgXK9O2etYQbXHvEllmtngEQQF7s3y8Auu0ISqmEjpRSQg1F7SmURvSWRc9x5uRmW3lplGdhIGQGKlMfBXckeN22toxR1pW73sckJb9S2Yh1q/NIoaPU4X0LLcFLC2E0lw0P+fs2qeT048EyExSluksoSk8KtZnqJUX3yUiR/gbwKpzXRU2AyRGUJfxiQuva5PRqiMUUhFAjjVHXQBjGdCBN67hW1wR7ZOyTGGYyZB7mIWI3vztJ2o4sPvfUUNlouP1WN3xoSs4MYprSDr8XT8sFpuQrLLb4ucg/tylMkxmAuzwNnW5d8FlUOClE3zMCaaEAMKI/qDi0WfnOlo4pClv4pWpAdILTD0n5AIml2yvIjCwKbwC0ZKmJylXsqg2hhOKZjqpKS7TYxglR2KnBFAVcO0Bvk54KGL6fYSZor/LzgYVemxMmSlNDUoohegMEN5kM3bneGnWwmr6zP0dUcGYw+CrZrRNR0o0fYi4fnDNK9qH4BLZ2ygd9xIpfW9nRO6kNuY/7yQA6KZSx3RisfRxnRpsDWOiXXSayAFgvkVBm0bpJyfb5zUrTZfVwsnZzv5a2SeesQtGfkDcFWHFiyHAEjNlyppzRga1nwXisPfaWg4TDHPFOaQ0+aO7s5jszy0lhEwv+W9mgimpsKm90h2S+XPMRap4n7RlNk u43zUfTQ 1HJCVD6lm0PnGQsHeapqNeM50CbRIcH0fX3yX3DoFzgZmkArn7SHmtxYgsfouuvrVMt3juZuXkneze43meXf5fkJ6eQe2q+nHKPrVgTT4dBCq4U3+/nSIaBj70EUpgFZBbn7NE83pC3RiUTAbDhlEdh5kcOtvK58CoCytzes50n6A1YyiHhDyPVtHc8aD5+6W+mE1VzFYf/acjdNS9A8ipRiNeHlD/mX024L6hCcE5Qw/hwE+Tx59ONbU8at4lRhXkDUnWF/ZepzuAqeNKPUnuE4UL2YFdFG4BmLCJFp1z4yBDxFuUieRoC4wxPVrJBDzIEOLT9GEOUGhQH2wPJ7z0OMNMVihIdOxGzf53yyESrxQHfYHrJjhqB4zDZAXiKiX+1x5pJGkudye6E1CFrCclB0OnebCjdtq15asB/EwDiMQRrVzsA+2rtEeQN2dR6QLEu9T 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, 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).