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 04C11C6FD1F for ; Tue, 2 Apr 2024 22:58:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85A456B0093; Tue, 2 Apr 2024 18:58:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80AB56B0095; Tue, 2 Apr 2024 18:58:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D1EF6B0098; Tue, 2 Apr 2024 18:58: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 501BA6B0093 for ; Tue, 2 Apr 2024 18:58:47 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0A8D9C0AAF for ; Tue, 2 Apr 2024 22:58:47 +0000 (UTC) X-FDA: 81966108294.25.9A96092 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf02.hostedemail.com (Postfix) with ESMTP id D89648000A for ; Tue, 2 Apr 2024 22:58:43 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jzBKipKR; spf=pass (imf02.hostedemail.com: domain of isaku.yamahata@intel.com designates 198.175.65.12 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=1712098725; 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=odURK93KIuk3nO9uz0C2T6FLjFg7i6lk/D+X7g7W+dw=; b=w4zAmN9JJOanZinaOEg5u0qLFS905dvrzLgR4a/DelbLi4eMd3yENWomBiTFTvlBoWlFFh aIUIVCOdwfDTpsNADslV2OTvfSkqLM60UVx5Du2h6DWaL8f8CE4lumQDmvwIWfNEzzjouW YPW2roKOBDOfX7lyFDIImb7tQchxszY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712098725; a=rsa-sha256; cv=none; b=kYZ6fyiDd59GBniNXaWxkB7ra4zbex/DDjFrXTx3BGBZMkeotH56jVbgLrFPp0KbKab2o2 Trqmu+pg3SRrpl32ekGoOpISUzDtRRWcj8DnTv3S2J5Cp0Ra2+KQNmdZgC7SnBUuvVLAs/ YXsLfy9WwdoeZP+K9tq+Tam7fQP8Zao= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jzBKipKR; spf=pass (imf02.hostedemail.com: domain of isaku.yamahata@intel.com designates 198.175.65.12 as permitted sender) smtp.mailfrom=isaku.yamahata@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712098724; x=1743634724; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=n9PG5Gd9QCdKP+TIsy1Z2jPRkRgvC7X2SZe2L3r5+MM=; b=jzBKipKRDKJkrGGPu6o61xXqF0S6uEJwX7IP19q4rk0xUPST1HeamlVa bbhY3Bbcc6kfCydEA560rseakfomZZE6FH6EpdjkwqK6SFhNXTNw25hG/ 6W2ocLpP0pFkvtWbdnCwxlj+VSh3saXFaJ7+Sl64ASEh4q4UX4C/yPLxD CZYXdzpPG2SFCf9/ipETigoj/YXyfjkZPCwdun38sGmH5lPqZ0FiOVbAD zXg/3IyswXVcLrfNa09BXeiZ9e1kWHcmQ6jEXVxceW8SYPvoyPU1n2iZp 5KP2Z+nB1RfAYj4slYOVuIj1mvLW5k2L/STg+sNjhbay6p/7mRBlZLIlW A==; X-CSE-ConnectionGUID: teOGliWWTw+DyzQTv7TjAw== X-CSE-MsgGUID: yCWoeo0JT8iTzFO1jL4lhQ== X-IronPort-AV: E=McAfee;i="6600,9927,11032"; a="18747111" X-IronPort-AV: E=Sophos;i="6.07,176,1708416000"; d="scan'208";a="18747111" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2024 15:58:42 -0700 X-CSE-ConnectionGUID: G+hY9GcpQa2do2OYHO31bA== X-CSE-MsgGUID: yZLG52nDTMerl9bXyvsizQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,176,1708416000"; d="scan'208";a="22978988" Received: from ls.sc.intel.com (HELO localhost) ([172.25.112.31]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2024 15:58:41 -0700 Date: Tue, 2 Apr 2024 15:58:40 -0700 From: Isaku Yamahata To: Michael Roth Cc: Paolo Bonzini , 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@intel.com, isaku.yamahata@linux.intel.com Subject: Re: [PATCH v12 11/29] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command Message-ID: <20240402225840.GB2444378@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240401222229.qpnpozdsr6b2sntk@amd.com> X-Rspamd-Queue-Id: D89648000A X-Rspam-User: X-Stat-Signature: 6e6by8ryr8zqjwdbn6mj88dohj9hyytw X-Rspamd-Server: rspam03 X-HE-Tag: 1712098723-512147 X-HE-Meta: U2FsdGVkX1+TaMsdfZe8UMNCi8XCPGBx0Ly3lHwmo9gTKRTWXdvCNO7+hIzjXBeVMwUeAzvyQLTjlQEwG7rRCzkr8UtwFIWK5hmjjmNj/xR9kgfIQDgNf2l0Dk+5M1bHHLgpVbx2V6dONA0HL9Fujkg9cXxs3u05CsRhnIAU/h7zk5UyjgLoJ/mj5X4uo6LrCWhlt8i+r7TbJo+pC4ozD0svTBTOd/hcneERuKc/eWX9+gIq2SXpO/KcplgYktCJzA6mnLqnU4rQ2u616387WtmFo4Yokrcajgjc850LnZzy9CsMbEU7fTLKxFT0Cl8z4TM/arT9araDz8yjrp+8RDkejhdRZNTTmG6rd7P0sIRbayrUK7Rujj+vV38aKkzPDWxwgCk1k0xu2TRefTF89TiKb72cgu7YDqFVAqrbMaDgzzPi0CHaPFiKD8hPD/uzzvK7DeUkVRZUgCNFrpKq+4DVSMkI+WJNMBYD825t0jqMBDKLKZux2OoNUJiiTa0Ky2hWjkw6/fC/iQIpm9plcaM3Qwvw8wGUtO/hukyjAJEciaYmRlHeJ2Jc+qe7eA6qfpolqfvzGsfzHnnupZgTD3339qUm9nD4pfQ+l69jSeDRbQL8UjEYEZ6StpUN6qbNca/Oz3eslrgr41okKg1Oil36bvsXqeWWGUy5+vTKaLQY7MV707yKvHlglFvQcqcfmq37KZsm8ZB9/soXQGEv8Qt+3J0YRD6gDtDEIf3nBi5m65RP9vuzOu0jKl3fjLG+uPnDP3b/h5UJpTE5qWsuBRlk9LKYQQcdD49V+PD1VcP5ltcrks9CpMRn9NO/RLzNPczrTMklt5GjU5rtWIK+MNVHWYD9GO97+kw5/bxFN5dFK9cnKHdJ3wUFJ/uFsr23o0MhOhll80CLOTH7YXymtzKh8ZD34E9cI5vS45eHyQRwGyUXsnJhGr0OlGQt+tInweUQPlO0mGlNoeSGjr2 FYsN8u7p 1MHrIdjrPjFyECLAw9cj3qasm/ihfFdA/z1KU8JBxnZ0Km9Dx0uznZLV7iYP9VDuNqnKXvVsy22t+PGSyONuzrpy5SyYcMSRFYYj2mEPSngSvYguRwb/d+Y9tlXVGEh81pOlH4uQq50ZT9J2Mtg536yITVuOLpO+b7FqiwTs7RA3uAjYj3KOO/3IK2GKNqntuEoKQrJmGOzp3PXhYxkOkEVELsXeBJq9YVQo0DslIp2222BVYeIoFVrxwA+mqphVkhJCEI3rBTULkJPQL82XenXD8aU1Ls+Ipi2wX6RL8KJAzyP8= 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 Mon, Apr 01, 2024 at 05:22:29PM -0500, Michael Roth wrote: > On Sat, Mar 30, 2024 at 09:31:40PM +0100, Paolo Bonzini wrote: > > On 3/29/24 23:58, Michael Roth wrote: > > Cc'ing some more TDX folks. > > > > + memslot = gfn_to_memslot(kvm, params.gfn_start); > > > + if (!kvm_slot_can_be_private(memslot)) { > > > + ret = -EINVAL; > > > + goto out; > > > + } > > > + > > > > This can be moved to kvm_gmem_populate. > > That does seem nicer, but I hadn't really seen that pattern for > kvm_gmem_get_pfn()/etc. so wasn't sure if that was by design or not. I > suppose in those cases the memslot is already available at the main > KVM page-fault call-sites so maybe it was just unecessary to do the > lookup internally there. > > > > > > + populate_args.src = u64_to_user_ptr(params.uaddr); > > > > This is not used if !do_memcpy, and in fact src is redundant with do_memcpy. > > Overall the arguments can be "kvm, gfn, src, npages, post_populate, opaque" > > which are relatively few and do not need the struct. > > This was actually a consideration for TDX that was discussed during the > "Finalizing internal guest_memfd APIs for SNP/TDX" PUCK call. In that > case, they have a TDH_MEM_PAGE_ADD seamcall that takes @src and encrypts > it, loads it into the destination page, and then maps it into SecureEPT > through a single call. So in that particular case, @src would be > initialized, but the memcpy() would be unecessary. > > It's not actually clear TDX plans to use this interface. In v19 they still > used a KVM MMU hook (set_private_spte) that gets triggered through a call > to KVM_MAP_MEMORY->kvm_mmu_map_tdp_page() prior to starting the guest. But > more recent discussion[1] suggests that KVM_MAP_MEMORY->kvm_mmu_map_tdp_page() > would now only be used to create upper levels of SecureEPT, and the > actual mapping/encrypting of the leaf page would be handled by a > separate TDX-specific interface. 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. - 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. - TDH_MEM_PAGE_ADD - read unlock mmu_lock - unlock slots_lock Thanks, > With that model, the potential for using kvm_gmem_populate() seemed > plausible to I was trying to make it immediately usable for that > purpose. But maybe the TDX folks can confirm whether this would be > usable for them or not. (kvm_gmem_populate was introduced here[2] for > reference/background) > > -Mike > > [1] https://lore.kernel.org/kvm/20240319155349.GE1645738@ls.amr.corp.intel.com/T/#m8580d8e39476be565534d6ff5f5afa295fe8d4f7 > [2] https://lore.kernel.org/kvm/20240329212444.395559-3-michael.roth@amd.com/T/#m3aeba660fcc991602820d3703b1265722b871025) > > > > > > I'll do that when posting the next version of the patches in kvm-coco-queue. > > > > Paolo > > > -- Isaku Yamahata