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 2A130CD1292 for ; Wed, 3 Apr 2024 15:37:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FDAA6B0087; Wed, 3 Apr 2024 11:37:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 686C36B0088; Wed, 3 Apr 2024 11:37:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FFFB6B0089; Wed, 3 Apr 2024 11:37:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2A1986B0087 for ; Wed, 3 Apr 2024 11:37:47 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A9EE3A1236 for ; Wed, 3 Apr 2024 15:37:46 +0000 (UTC) X-FDA: 81968625732.25.3FC5612 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) by imf16.hostedemail.com (Postfix) with ESMTP id 657E618001E for ; Wed, 3 Apr 2024 15:37:43 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WbtWuJ0c; spf=pass (imf16.hostedemail.com: domain of isaku.yamahata@intel.com designates 192.198.163.16 as permitted sender) smtp.mailfrom=isaku.yamahata@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712158664; a=rsa-sha256; cv=none; b=02lUMqOiy8OjhPXkWSlQyOCkkx2tfTf5h/L9zCnxTFO5kSY5GOrNsyfZU5eCAjBMh6qeVe q7gnNNt5xQVoIlpOJsOfBU2lBV8lV3iy8LieQKeZhza7ZoKcIRlXYuPx4YySchMd4gYZ3B aOV1cVAp2WqNGB4ZAhsyDbPlXCd+8XA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WbtWuJ0c; spf=pass (imf16.hostedemail.com: domain of isaku.yamahata@intel.com designates 192.198.163.16 as permitted sender) smtp.mailfrom=isaku.yamahata@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712158664; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5944NO2BiPJqraKYSi4s+HV5x9bjuo2LXYrEwGReMXg=; b=ySYhpGM2aTeZ30rUEY11qm4ho9fFhM06cuwKew5gg60jvjws6PgUsI7Ze7uj0Pm2iayw8o RnBn+VORf8xsZcikABtwzi1mcMIIfc1tU4kCpstRmHDAwX6h2nd19IBDRbCw6h505AMant 4TcKYs4FPiC4wblJTxuXvk8zQfyV1ZU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712158663; x=1743694663; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=QJChaVAp28BDDX83PqbBHFkbmbYUNuu15HZqdJSXkew=; b=WbtWuJ0cn34owHHDkeHurxXDt9HWlSmWvYbZCqP7iEElBu95boM4+qR7 4947llSRQC2oQ3TA5Rrnpy2Tnn3OQL9fA2bEo2W9JX3vEKx/JW4lyN6ja DXyhfhNqfwPU13oYA9CY87YxmBrFlZhAbq4n24+JSj7Sd4KMEpiacRyfx QJf3dTuPoNmOlNEyAyCMbp6YNR5OmOGNQEwl5AJjIqS+0x/Tz5uVP0nAA SZCDsGuFCY0bA/WnUxlPYbVDAkhCi3cWF4skqFTJ9dMGUmAUKl9gtRQp3 IM2ebGRAbfko+KTzbhRcwouNSKbcN0g7yr3jeLl9QMZkjp/jHNv2VWW50 w==; X-CSE-ConnectionGUID: VBMy+j9cRzKkhhgsCzKCdA== X-CSE-MsgGUID: EgM02gawRXmZetQwP1+mNw== X-IronPort-AV: E=McAfee;i="6600,9927,11033"; a="7978843" X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="7978843" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 08:37:40 -0700 X-CSE-ConnectionGUID: C9r8JNIGTH6X/XyVwhZi2g== X-CSE-MsgGUID: 1aG80udaTneHuT7+mWUbTQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,177,1708416000"; d="scan'208";a="23177428" Received: from ls.sc.intel.com (HELO localhost) ([172.25.112.31]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 08:37:39 -0700 Date: Wed, 3 Apr 2024 08:37:38 -0700 From: Isaku Yamahata To: Paolo Bonzini Cc: Isaku Yamahata , Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, Brijesh Singh , Xu Yilun , Binbin Wu , Xiaoyao Li , isaku.yamahata@linux.intel.com Subject: Re: [PATCH v12 11/29] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command Message-ID: <20240403153738.GC2444378@ls.amr.corp.intel.com> References: <20240329225835.400662-1-michael.roth@amd.com> <20240329225835.400662-12-michael.roth@amd.com> <8c3685a6-833c-4b3c-83f4-c0bd78bba36e@redhat.com> <20240401222229.qpnpozdsr6b2sntk@amd.com> <20240402225840.GB2444378@ls.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 657E618001E X-Stat-Signature: r1uhemq31n131utu58yyauahjb33tkzs X-Rspam-User: X-HE-Tag: 1712158663-774146 X-HE-Meta: U2FsdGVkX1+RikzrPu7E/+CWMzxTLr5/AZCqJvf+Sglg7x9O1PEKG+o8ufd9kKpGqzt+PEq8Yhvq39rKd6pa+6kdYptg0d/5jSDg6FXfaWvLZ/TlkQaJQvaqOdWwIvAB7m6/uVUgaD/kHkySsvBaapCFYNgW/alGsLoctYjUv2YJDP2n3lklXjd61KsnNxHbD74/bUYchTK5ti4+kTBDIaQcJihjEriVQS9ewGCsIO1xTcZcZJ6wL6nB+lqn3uJBVntyRtwWCOOGUj5hacMS1KwO5i7PYSueNz2x5GXLqm8IOS8pPADTr539FS6hO4dNSlmJsgwbjl0iNaxWOdYkexhgVrHj/WW6hnebRtNVseB4Tzfb2ZvFG38xGcdNbwtBg4OBKmtbdad+F85CteiQDQlMiZpzasDyFSvwVQUpm5+aSz4x1gx8YL4WSz1ZHQNqljMocUSn4Wi+H97mbdPSDYQNBhjGBM41xLwTwpdpB0OfwOmtce9IuaCGjipXbyPe5YCrYyvOk/stUcwovuWfaSZcT8UiOP4iW611Q5fynEfr9tmr+WyUw5xx9x4+/h4JQWht1IDJmo8HURZluK8ked+vGrAzFAinAiIDDR9FEfUhk9kWeUO8QKPYa8Tbe/nYRjIsf2b3LBoW7ThM02J0ktDw91kHlUuwtU5Qn86nJFldbUluiNhZxyk5WBXlynNS3zAEpciwDyg5OkkiHksKyNSSgTRE5e9TalcXhALCGiF9W5WrL0xB8h5BWC8829DlcnxlCdDn32Vufh6JRpOzXqznwEXcINKSlaKE3kyQoxnnBj3SRZmn+5yxE2rr5wF6YJ2Y/+vQRrulasdH5KDx6O9fWVpYxxxQkuPWFK02SPMeqKtU8EaFyUoQd8Gs7ti1foNYgg97P0Rnz5HFzDogVe9efWBEjmhbIODQAHzX/GJQtsAYLOuzGsUHPxhamw4Nxkd24t8iYYsT/i64bj8 hMiSsDD7 089UmkjGrEpBiRAqvqU2arkSq/bIqFllX3CDwJml6PHVpw9nXoMTIGfhsxyd9hS4P3KkL8bW/pUlrSIjVYeHMBXvl4RjVqbMaIW30eQI8UFY75mp5p3P5iYw3XaVSWPkbn01Hztund3G3GIo6gEoxrqOSmF14kHUrnMlFZ9OB/pG23w/0GFzKbO/0XSveVg/KXm78xuq+h2NBfZE4WbzFWdQHSZGfIGhRT/RlAei/1EHq+PeJoYJDeJzD/l3fs9J5217x9d1cysa55Dg= 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 Wed, Apr 03, 2024 at 02:51:59PM +0200, Paolo Bonzini wrote: > On Wed, Apr 3, 2024 at 12:58 AM Isaku Yamahata wrote: > > I think TDX can use it with slight change. Pass vcpu instead of KVM, page pin > > down and mmu_lock. TDX requires non-leaf Secure page tables to be populated > > before adding a leaf. Maybe with the assumption that vcpu doesn't run, GFN->PFN > > relation is stable so that mmu_lock isn't needed? What about punch hole? > > > > The flow would be something like as follows. > > > > - lock slots_lock > > > > - kvm_gmem_populate(vcpu) > > - pin down source page instead of do_memcopy. > > Both pinning the source page and the memcpy can be done in the > callback. I think the right thing to do is: > > 1) eliminate do_memcpy, letting AMD code taking care of > copy_from_user. > > 2) pass to the callback only gfn/pfn/src, where src is computed as > > args->src ? args->src + i * PAGE_SIZE : NULL > > If another architecture/vendor needs do_memcpy, they can add > something like kvm_gmem_populate_copy. > > > - get pfn with __kvm_gmem_get_pfn() > > - read lock mmu_lock > > - in the post_populate callback > > - lookup tdp mmu page table to check if the table is populated. > > lookup only version of kvm_tdp_mmu_map(). > > We need vcpu instead of kvm. > > Passing vcpu can be done using the opaque callback argument to > kvm_gmem_populate. > > Likewise, the mmu_lock can be taken by the TDX post_populate > callback. Yes, it should work. Let me give it a try. -- Isaku Yamahata