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 C6B8FC25B77 for ; Mon, 20 May 2024 23:15:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C68A86B0082; Mon, 20 May 2024 19:15:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF1946B0083; Mon, 20 May 2024 19:15:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6A796B0085; Mon, 20 May 2024 19:15:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 868C76B0082 for ; Mon, 20 May 2024 19:15:34 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AFB821A0C34 for ; Mon, 20 May 2024 23:15:33 +0000 (UTC) X-FDA: 82140332946.07.4086F40 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) by imf05.hostedemail.com (Postfix) with ESMTP id DC40D100004 for ; Mon, 20 May 2024 23:15:31 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Wkg24yvt; spf=pass (imf05.hostedemail.com: domain of 3ktlLZgYKCK0fRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3ktlLZgYKCK0fRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.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=1716246931; 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=twyGBTDDHaKdZ8SvbyxDVnqYzF64Bkyy6CUrxLoAK6Y=; b=QIodP01f24rwLBtuyjnsUNwTJvWH6ro+plEsRKSqHYo9QGL9X36eUGHAfUlAlGcJZFhPe9 +1eRmD6SVvZknvYAbxtz+3er31AnkxlEfKN3eT39akxc8xgQLbRFPQb5qdrLqxbM/cbT1Y B6uSpbFcMPK4Gkdp2X3dnZrwlspdGmg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Wkg24yvt; spf=pass (imf05.hostedemail.com: domain of 3ktlLZgYKCK0fRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3ktlLZgYKCK0fRNaWPTbbTYR.PbZYVahk-ZZXiNPX.beT@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716246931; a=rsa-sha256; cv=none; b=oVQR3+cYMvCIdK+G3kuHNybywCX8fggcsX92qTbKNpvWNcZ1wyMZBOb7GBA0CJAW9Izama BA+/taXCici1MIRRaTAsfk6yM1jCnm0eY98IGmNwE2P8eInp10Zge8+sVZcWKqvYkYJ6LL 2Xd1WGkSc7H/St/a3cjFukCLsGV7HK0= Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-5d8df7c5500so10206752a12.2 for ; Mon, 20 May 2024 16:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716246931; x=1716851731; 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=twyGBTDDHaKdZ8SvbyxDVnqYzF64Bkyy6CUrxLoAK6Y=; b=Wkg24yvtNEFVp0kWFf6ivnAF+qnhCWPAi17x3S67+RkYPb2ZueI7jo/IriASJt3R1M 4Ajif4Ng701FdxVizibbpJsituitqeNHZYCY8/PPIPeJX/CYtsH7tJvgOIuFkRjT72Ub llNqyUMkBD6ES2e4W+KjiCLycRcsWItBBn5bf4H2TsZM3ZPjzpfsIR30ZBxfDfgCT4pw lLann34IukLfp8zOoFhcXRGi8kMQSv57nG6LS0gcVEranFMRpIuZodA0Q/MW8YGqi9/W mflNp9/Jcj2n+Af21MTthK8/zWUVT8kIZkVG0J4AtBsxM7LqIwyXG8sXbkS0kbXVDOlN X4fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716246931; x=1716851731; 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=twyGBTDDHaKdZ8SvbyxDVnqYzF64Bkyy6CUrxLoAK6Y=; b=YYHblPscYgGyhQn+DPknRGn/XSq8Mgkz3JQj4DAMFxjP1eTM9mxbJaQUz5B3XhQRX1 Gad1qeWtt2s1U3mVHJFw1HWquRYSMo+/W4P47OhnfgKTfHESb46Vzp6tlvS8zSsXhxxG ECYJ2T3krG9Cg9bFJb6ZkPgdB1fjVztAbjVHWR/4nthzeUkxl282IkiT7OGlUopitBoV JwgkmvqqqQzsr0TAWSIBxQfD0ivCpLGfKMUq+u3PS+ucFXKN+JXMujZnvrAFjIROpjG+ 6ScmuLKbCRv2Th3rCEBm6BT+eF5SKn7jhdpTfD2wQh8wnfAKGwmS3d9FUH6Iv162bIaL Oxgg== X-Forwarded-Encrypted: i=1; AJvYcCXxnSr3uR6LZv/yod/8ZF3tcw45T9N73AxxJ+uiMLeNYSb9YvD7nwqc4mAXcd80AmGOxeGOC11MnyFIGBFrhRAQMpg= X-Gm-Message-State: AOJu0YwC95l/w6QGHBBHpx9umfIRGWxYDGoj/RyRRNgxyMbcRJjTBvZk JRnDkP0/WpHXpXkm2XWIHAdwLta/LTuUQdxA+yZt/uaE5DfJCDOdm/73k70Kxdmgu98W8jZjBnQ DGg== X-Google-Smtp-Source: AGHT+IEb1f5CvIuuxXv4wmgiPRrmKycduR1sWh9xhUNpPR81OBtrrM1PtIOQ9UT8e0m4a7A35MqsxNzI03I= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a02:688:b0:655:199c:eb1b with SMTP id 41be03b00d2f7-655199cebe4mr46923a12.10.1716246930361; Mon, 20 May 2024 16:15:30 -0700 (PDT) Date: Mon, 20 May 2024 16:15:28 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240501085210.2213060-1-michael.roth@amd.com> <20240501085210.2213060-14-michael.roth@amd.com> <41d8ba3a48d33de82baa67ef5ee88e5f8995aea8.camel@intel.com> Message-ID: Subject: Re: [PATCH v15 13/20] KVM: SEV: Implement gmem hook for initializing private pages From: Sean Christopherson To: Kai Huang Cc: "isaku.yamahata@gmail.com" , "kvm@vger.kernel.org" , Rick P Edgecombe , "michael.roth@amd.com" , "pankaj.gupta@amd.com" , "tglx@linutronix.de" , "tobin@ibm.com" , "liam.merwick@oracle.com" , "alpergun@google.com" , Tony Luck , "jmattson@google.com" , "luto@kernel.org" , "ak@linux.intel.com" , "pbonzini@redhat.com" , "pgonda@google.com" , "srinivas.pandruvada@linux.intel.com" , "slp@redhat.com" , "rientjes@google.com" , "peterz@infradead.org" , "linux-kernel@vger.kernel.org" , "dovmurik@linux.ibm.com" , "thomas.lendacky@amd.com" , "x86@kernel.org" , "bp@alien8.de" , "vkuznets@redhat.com" , "vbabka@suse.cz" , "ashish.kalra@amd.com" , "linux-coco@lists.linux.dev" , "nikunj.dadhania@amd.com" , Jorg Rodel , "mingo@redhat.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "hpa@zytor.com" , "kirill@shutemov.name" , "jarkko@kernel.org" , "ardb@kernel.org" , "linux-crypto@vger.kernel.org" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" Content-Type: text/plain; charset="us-ascii" X-Stat-Signature: eepo9ffrrkutmfr3i78w8ogxoey37347 X-Rspamd-Queue-Id: DC40D100004 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1716246931-105479 X-HE-Meta: U2FsdGVkX1/oNzS74T2Pf+8885yrmXcl5XT4EKF6nLa1zmCmfvbJPFC0j9dkXr9trx/+Dc/uU/d2+NERnJ/JKzSwr5rxGXmqegEP6+GSnFSWL4XJ4sF7/Y+1BI9oIv0Jpx0yS698y2ADNHoTLGC8qjrHDZC0ZQcSuuQ9DR9VoNdZl++wqw3AClc4qhuN7CXdC4rYbFLDhS1gNa7qk9i8YH+A4s43Nh5IGJFuEWsIDUxm3Hdd0IYP9rYc7zSLORZoaAiuOaYCehByFR8dj5Ri97csAJUvK99y2PsyD1B0Hx7UHLCHpatzvAE6fhJ2pvjzfNGY1glpKo7TtCxXo/YD6ZeSwzAtwlTK9wFHi5/rwQJZCaiNts36l0m90qKNRgaxNa1NwguniyV45elfAla7lV7rhsSbjKbvyilcDtFR2jxnlkqcxxtCA/nBYJEPR8xtysorunQLzkwm+67wqetvfMCWB11u9oNryRocRNE/XL6AMdBkt4ajD8fyrGgCynb+u5PTHXcZGOp3munBAFstyltwCieWTLJpaXIKqd+zuKqvPQcAF28Vc9e8gX2zCvA7v0C5AfxoU67qCAfjjVovmWaV6mMn3gifMuG+kKBhpQUQlEU2XgjVCSqf3Fgac+6iys4PRDfp9Pe63S15aKwrZb90kYoxBdmYSHQRUka3ZlkqEqlydZGOzcKZFiVXHRicVoehmdgqAg0x2mBa98w+ukHpag5zh1nulfs60IPlXyBJRFIFmqQqoA1ztNmQE3kRQYxzBhzLdwUpgJgtbp3TCPQfXZmAVZmfkqBC/oQlgzm9jdktPZ4Dtp6N2E716IpOW7wLg1STFCQ5X2Sr9KxyvLMqEgK0Sfa9MKIEF3wo3Pat6c3u6kDj6qQPsSOkWPC1iY+vy6d8WrnvUA/V/6GAK2VV4LlZpWejyYFC6tpDt3H8azJH3+TI6U4Xsm0rxS0IQXCD0c7O1aG+A5ptDU8 00o9ebFG 2/xK76O1cKWzSZdQ/2O3E61sqzrQloF8MgF/8jeu26b/VDuf4IilNGdIGSxFVx4bMP3l9QmILCppGGEw7ti36Vb686J25lwKS8/IxCBPGROqOaB8Zqu1+7dArHp1if/1uAMyTLuBardLxLYfZSNe4F5p7lYfUqBeejSkHack8OF9M4vCW6icQsjYKeiFqLaGQj/6GR1k72+bZq2wYsFoaqE9P6Imyr8mGCg2FJFWbE4eW5kZKe9/rYjMWid459A783HH6mw8NyNeNdBG8gM1T+wtD/7bAmtjYcnxBRCNukmNaw+expHeRn2Yf0kT5xmXP2RBa0SkI0I+SW0Y0S6snQ71OyGfxAy2V68SoM3WCEtPUVhJgvH/E8u9ObYMdUJctbqoPvbH1TG5txDBgkL44OdgYjSDuXBCcEtMu/T4K8ZGXykE/MPh6Rblm0dwWpH8ZTJBlaQRX9Qh4vUKJ5EItmn3FLyDB5cGJiPNairqaRT64cOW3SVpfS/+CAN9qTYARaVtrYKEyYet+5QsLFwE5HDZo0q33AIEE+fmULz/ZrNG5gZanoubFe5RTLBfc4IRCF1Giw7FXIVZqQvOyVqV2q5laaTyuEPWd8eVag9e5iI9+Ucjg2WIR/V1lMDW9TGAiaQafgPRW1lB8IX0RxF0gWBUZcv9XE9o+Ihx4YAsULqapIlX/w3+5fr40y5AoERkB1GKt X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, 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, May 21, 2024, Kai Huang wrote: > On 21/05/2024 5:35 am, Sean Christopherson wrote: > > On Mon, May 20, 2024, Kai Huang wrote: > > > I am wondering whether this can be done in the KVM page fault handler? > > > > No, because the state of a pfn in the RMP is tied to the guest_memfd inode, > > not to the file descriptor, i.e. not to an individual VM. > > It's strange that as state of a PFN of SNP doesn't bind to individual VM, at > least for the private pages. The command rpm_make_private() indeed reflects > the mapping between PFN <-> . s/SSID/ASID KVM allows a single ASID to be bound to multiple "struct kvm" instances, e.g. for intra-host migration. If/when trusted I/O is a thing, presumably KVM will also need to share the ASID with other entities, e.g. IOMMUFD. > rc = rmp_make_private(pfn_aligned, gfn_to_gpa(gfn_aligned), > level, sev->asid, false); > > > And the NPT page tables are treated as ephemeral for SNP. > > Do you mean private mappings for SNP guest can be zapped from the VM (the > private pages are still there unchanged) and re-mapped later w/o needing to > have guest's explicit acceptance? Correct. > If so, I think "we can zap" doesn't mean "we need to zap"? Correct. > Because the privates are now pinned anyway. Pinning is an orthogonal issue. And it's not so much that the pfns are pinned as it is that guest_memfd simply doesn't support page migration or swap at this time. Regardless of whether or not guest_memfd supports page migration, KVM needs to track the state of the physical page in guest_memfd, e.g. if it's been assigned to the ASID versus if it's still in a shared state. > If we truly want to zap private mappings for SNP, IIUC it can be done by > distinguishing whether a VM needs to use a separate private table, which is > TDX-only. I wouldn't say we "want" to zap private mappings for SNP, rather that it's a lot less work to keep KVM's existing behavior (literally do nothing) than it is to rework the MMU and whatnot to not zap SPTEs. And there's no big motivation to avoid zapping because SNP VMs are unlikely to delete memslots. If it turns out that it's easy to preserve SNP mappings after TDX lands, then we can certainly go that route, but AFAIK there's no reason to force the issue.