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 41EC0C25B77 for ; Tue, 21 May 2024 00:30:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E66A6B0088; Mon, 20 May 2024 20:30:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7960D6B008A; Mon, 20 May 2024 20:30:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C956B008C; Mon, 20 May 2024 20:30:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 443F46B0088 for ; Mon, 20 May 2024 20:30:20 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EF8BFC0EA5 for ; Tue, 21 May 2024 00:30:19 +0000 (UTC) X-FDA: 82140521358.13.C1715B4 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf24.hostedemail.com (Postfix) with ESMTP id 45E05180009 for ; Tue, 21 May 2024 00:30:18 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=N0pH3xCy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of 3GetLZgYKCFgI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3GetLZgYKCFgI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716251418; 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=6ptfnRWr6+WaSf97cvh4fEBETpjMq9qszm8kFWwt98g=; b=sV3dem4GLmtDoXpWC14OlBOe9NoUEKEBjNlhsdbzYz7N09foIiEXEK/HzrRL9NzHzreFBN rS+x4lFwHw+MySHY0+yoeQplvMJNEc8p0qbzFQoRtl9xna1rGgc4wV3hDBMampUJC4qwHV s7J2RYHV0OgDy9tyV0tzz07C5SNcVSo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716251418; a=rsa-sha256; cv=none; b=Lp9q0cHqnxOXT4I+45Lv2PC+4UObP8oYYISSiJawiLBz4PuOVyjB5lZHobpo0Cwc3y4iUe zl0XWdsu5EMWopy7GxtCYCXZdqnQzw+7CAfpRGzzyyOgbi80y6v2Xc/zt39uYY5ZO1M2hn e7XbpUWs1pBMeH8z3O3r8VCu1/1a0ak= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=N0pH3xCy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of 3GetLZgYKCFgI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3GetLZgYKCFgI40D926EE6B4.2ECB8DKN-CCAL02A.EH6@flex--seanjc.bounces.google.com Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-61b2ef746c9so201365737b3.1 for ; Mon, 20 May 2024 17:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716251417; x=1716856217; 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=6ptfnRWr6+WaSf97cvh4fEBETpjMq9qszm8kFWwt98g=; b=N0pH3xCyYczWqEh6aThvchXoYcCCUkT7WmQNvfzYXfKSh215i/m5JRkvqs1wZMfXfo 2v/yMW9J6OkVjSuzYjUfu90o5PSaJaTDzyLyO1MU4qm8X9tdXXpUPuQTWyH1MGUPn5g6 hFKo5MPSZERbVl9fM6BQSqJ1PSUkJHkaVGdtyPdwq9TZvMlFs1wBJWR7apVHDPFj7yDV LKPJ+1bCNs7YQC1xiRpzBkW3ofrhDFz36NtDmjf4Vmikk1P73Wak/AePhCXQMmm6RlHL WIepof1Xj8qxvn30X00KBvDHDdwxQ0cWAMwTMaOSF9Z8GYT5vbL1EzrxX5otP38Wvz8a sKQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716251417; x=1716856217; 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=6ptfnRWr6+WaSf97cvh4fEBETpjMq9qszm8kFWwt98g=; b=J9C13cTJzi2CfM4yG+xY5oxwCUBQZehwYGklI65wJ0/ZWEFHaqHk2JkhlwTQ+9S7ZD XOpruVUixrzeBlMkkUZ990e2awzuU7Slp0HDP6ZdFUcbBvbHs+fs0oa6USXRek4juWw/ KUNy2PXYRiW+eiVTAYv04lbuql4vsOoFG/FM72/ATRiIKhcAI+4euTbOarf/XySPrCoO VXU5vjKwLZP31edcz/W52Bqw3mhsidSRkvbMcJxwXJp/NYEFFmVMMBlcyrNwuU499yrZ PdlvPpmMd2emL2WJOTnEXd7xhrVln8WLhRpOgLxpTfnCnSIMf7Qjn6xRX3JCoScNL5CH Rxtg== X-Forwarded-Encrypted: i=1; AJvYcCUZdaBXIsthq3sNYP/i5RfB02pffD4iGVMELAblPxzlcfZWXC4lH9Eh6BRJQuxiAXkdOBH1Sn20AA/SXgn4AQATabU= X-Gm-Message-State: AOJu0YyEx0U3rK41m6My8TUN41AQ+FDsw+A/oeTQpoM3YocH0/5gxLCK 4PEOrnxQ1+BEvLPawFnGHmhDAFT7J2R9LrgkPJSNMPxlX/HK6d8XM+mxZf/EU17pFL4CbOavfkw Ing== X-Google-Smtp-Source: AGHT+IGATBiWxOmW/cqDglHQgdjt/m1Tibs8w8tsXY3vEs4VxyaK5Qg0aR3gdp+bWKqZMm0eBuFbJ1ZMUNM= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:c01:b0:de5:2694:45ba with SMTP id 3f1490d57ef6-dee4f104643mr7926731276.0.1716251417124; Mon, 20 May 2024 17:30:17 -0700 (PDT) Date: Mon, 20 May 2024 17:30:15 -0700 In-Reply-To: <1ce87335-2ea7-41c4-8442-36210656cdca@intel.com> Mime-Version: 1.0 References: <20240501085210.2213060-1-michael.roth@amd.com> <20240501085210.2213060-14-michael.roth@amd.com> <41d8ba3a48d33de82baa67ef5ee88e5f8995aea8.camel@intel.com> <1ce87335-2ea7-41c4-8442-36210656cdca@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: 7haa9s94fxqmqiuisfdh865qo7a9gze3 X-Rspamd-Queue-Id: 45E05180009 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1716251418-279618 X-HE-Meta: U2FsdGVkX19N5LruRA72oyZYqP+Mq57mEAGibDDkQFg9HzK4UkAvIJVs3B85UM0t828Le9GskT6Rs8jN05tKy9UTr/w6TPH0khnvt2DWvSAMTRv3VA1TRRr75nP+yEPnYCMtz9+gDsZxOmV8DWFbVk0cKy+PQBrJ5vQ3OzqVkznUWScnDB6+O92bwbYS5M4rURfhEVKZTJ9VIPyd7Hx025S2wFGXnpZYCmCbKnXWWA+/wHCwZS9yjjwZJKx9Oq96xB3zHC10hbQMigaIjVKst93d5Mvu6WenFdEAzFWf79nGHR0tY45a+GyVkTLofMXiMm1Fg/KsoqUoU2K6Ml1dfNvx8ejYYkBs/wwdKrvw74ugNPN3Fr4lJqIJaisqUiqBPhwBB0HG51rhMu2WETwYkKR5ZdDYZuMLtHz4TKg+XA5untREApjtWM0wLg9Uj/W2CHQ6sHJ3JTcR43vMVRJz51MCe21ZgRbI1cWd2iQKI31pN9dPtue71BfWpnlnFWx/zgpOI0z+ZBaXpLejggiqjDOPSFEtSJ5ujphVsGoz7cxXB9PJfsAlz05pVWRSs4gW65fc06p8fLhGm1PZA9FUYNUpzHyCIECGFn3otZxPr7bb3RoXDMjwiffEnvwSyiUIYa2YIN2hfdmceqB/6VXgnRZ+c1TO+kMWh0r1j827MZdY3+VHGPE2oKjoLOc9ZoiUyVcF3PAwLd59biHjB9xeqkxan2cPUOQexCu/TgBX1X/LtnazrsnyPvw+9sC5futGv/47iNt1nkJeNDHbeZ15RGogQG1omUXIGybs1YTsGGTb7Ku7WiKyIL39Kld6pkpxUbMuXZyPTRNm0ma2jnNEYvB1/G9XQKSk1Eh3pwFDgv/q5vflglFUSjIkfAIHDPhjhvpaD0XrirljizudpD8Ekoxn42aqvulRw1pewIiBn2xfz8QMUXnVpmVDetiRrtHs/5TjjD07/WHwEF08m89 O5TVfWsw exfmDubauFbgtadrpt9v7bC6h96sYobpoZ5hzg2FGvbx8E/hkaN6zvtCcJpq1PeUHCCS+EEwbJrYg06V/p9HxZSnJDifJkFEOZIFP25VvLgpKt46lYy8pKwEVn127Z8osjanQY0vJlN1grNHc4m30Fmh02Jb/NLmtMhvUuEH1504laION0VehDfgEu7ZcI2TuJ5D+n3Q/hFV+Vw/xzdUSHWhmffRowxbwtBYUtIuIQDdPBua9uR65WaqnO+vvuk+Ri06RCBKF+/6QKI/rGcXrHQFsAqsFu6BpEfBJ3pzIe4NWf8YxTmSDlCGM+9SMm97urHUhul3dxmBrwNp0/O/ifWc9X7SKCMr5wdKm17w0Tf5GE8xBBVCyZfqB1+xmW8TnYqh8STcKfQ5xlfd0X+zAxPDQWYkbBvmPYJmUpJobal42DtSxiG+t2OmD52jVV2414LdT8G06UmMxmbe0s1kBHfh+94co8vdlpv6a54jImRxhfR2isr/O7Nb2o8cpG4ju3s8Tow+4007GHxnoioNm1GMLyvO1VfPBagEOMg2DPX4JyDLasAuJhGk0WRh4v3p4SLOobAQd/+KVcFebRJKXoorD5qfkYpcB/kOEpRoqpTGZm+0M6kC1cMvcxfmWGLoM3TLPkepUGwndzs6FH++Syt7XTrj3D/uZl8Mhft5O7Ud08322utENUPtzunratawDVlDf3hE6yp9+Lf3A2SrIsB0mMEtZ+nr+rwjOF3LXHJEU2kmZOTJoUnODo9MBRDfTQ41zpWCMmLaWhNkplR3eO20/ZuP3OI2NQEBp8ZmAF27weqQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.014848, 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 11:15 am, Sean Christopherson wrote: > > 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. > > But is this the case for SNP? I thought due to the nature of private pages, > they cannot be shared between VMs? So to me this RMP entry mapping for PFN > <-> GFN for private page should just be per-VM. Sorry to redirect, but please read this mail (and probably surrounding mails). It hopefully explains most of the question you have. https://lore.kernel.org/all/ZLGiEfJZTyl7M8mS@google.com > > 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. > > I am not certain this can impact whether we want to do RMP commands via > guest_memfd() hooks or TDP MMU hooks? > > > > 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. > > My thinking too. > > > And there's no big motivation to avoid zapping because SNP VMs are unlikely > > to delete memslots. > > I think we should also consider MMU notifier? No, private mappings have no host userspace mappings, i.e. are completely exempt from MMU notifier events. guest_memfd() can still invalidate mappings, but that only occurs if userspace punches a hole, which is destructive. > > 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. > > No I am certainly not saying we should do SNP after TDX. Sorry I didn't > closely monitor the status of this SNP patchset. > > My intention is just wanting to make the TDP MMU common code change more > useful (since we need that for TDX anyway), i.e., not effectively just for > TDX if possible: > > Currently the TDP MMU hooks are called depending whether the page table type > is private (or mirrored whatever), but I think conceptually, we should > decide whether to call TDP MMU hooks based on whether faulting GPA is > private, _AND_ when the hook is available. > > https://lore.kernel.org/lkml/5e8119c0-31f5-4aa9-a496-4ae10bd745a3@intel.com/ > > If invoking SNP RMP commands is feasible in TDP MMU hooks, Feasible. Yes. Desirable? No. Either KVM tracks the state of the physical page using the guest_memfd inode, or KVM _guarantees_ the NPT mappings _never_ get dropped, including during intra-host migration. E.g. to support intra-host migration of TDX VMs, KVM is pretty much forced to transer the S-EPT tables as-is, which is ugly and painful (though performant). We could do the same for NPT, but there would need to be massive performance benefits to justify the complexity. > then I think there's value of letting SNP code to use them too. And we can > simply split one patch out to only add the TDP MMU hooks for SNP to land > first.