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 E0EE9C05027 for ; Tue, 14 Feb 2023 16:06:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67D4D6B0081; Tue, 14 Feb 2023 11:06:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 62C966B0082; Tue, 14 Feb 2023 11:06:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CCC86B0083; Tue, 14 Feb 2023 11:06:56 -0500 (EST) 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 369746B0081 for ; Tue, 14 Feb 2023 11:06:56 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0C783C0EAC for ; Tue, 14 Feb 2023 16:06:56 +0000 (UTC) X-FDA: 80466376032.04.ACAABCC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id E6FD54000F for ; Tue, 14 Feb 2023 16:06:53 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CTHUOp6a; spf=none (imf07.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676390814; 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=xB/bwHUPt+tors+Z68y+j7FdmLb0N8TJZt0zwsIot58=; b=q0j16gga+eWRON2tUylgxEx/+w0ZFBtuFV3lF4xq1F8TkGrZLcHvgTvxHJf62T+LcHf+b3 bkE/VkbOBoPdC1SCj5W62Rm/W0WfTYUTVJLxxELDN4Wg2XMAwIQAO/Y7VQbh3KNAvadIq5 tztlp6BVWmBayd6jfXdHfUOXbGKdcS0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=CTHUOp6a; spf=none (imf07.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676390814; a=rsa-sha256; cv=none; b=LVZ6XIa1DUlnkGwuKuxOqBlI/BdI4K198AyoUkNrwX1ppojRZbtAalmmvSMl1rBGWpecms HrQNMxMRNufc1bkNc+x1csA8TM5w4q8RtRdOfZZ3WTV9th0SbyfpyazQfdNfUnyZrquj9r U3Kj/tuHvqHd0YbjOBB7uSdDqSf+m9g= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xB/bwHUPt+tors+Z68y+j7FdmLb0N8TJZt0zwsIot58=; b=CTHUOp6aV30XJQb0TsxIkcV0H/ EKB/ASpBeMl8tqBBoOsmGjRD3qlxw0BZ666waF+v2V3m3K3h7Cskgjfihb/AKeQZo/w3ahZNW5Ugv skC8xW1AByrYgc/8eCx8hqxbmaEgC7lVxSnQW5NQ8JRhF7y3yEQ67lBLZBQIwhtAnOsvFq7oJ9cl3 ZD73ZFgPKnD41RDl/hQQni8Ivb7JLhOI1Z0gFj/ICHRn93P4lokxy6W9TpkG5bbuXbhaQXyo3U4m+ wyX5joNmyufLd62fUtHsNInOo8TARUtKfKkDrkIJ3ZQpkWF0my9Vi6AovqVcKuizB4cv3CfmgzSkM 5O8lTg7A==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pRxpQ-006cuy-Ho; Tue, 14 Feb 2023 16:06:49 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 7D6323021E2; Tue, 14 Feb 2023 15:12:11 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 603C223BDBD82; Tue, 14 Feb 2023 15:12:11 +0100 (CET) Date: Tue, 14 Feb 2023 15:12:11 +0100 From: Peter Zijlstra To: "Huang, Kai" Cc: "kvm@vger.kernel.org" , "Hansen, Dave" , "linux-kernel@vger.kernel.org" , "Luck, Tony" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" Subject: Re: [PATCH v9 07/18] x86/virt/tdx: Do TDX module per-cpu initialization Message-ID: References: <557c526a1190903d11d67c4e2c76e01f67f6eb15.1676286526.git.kai.huang@intel.com> <86a8fe2f-566a-d0b9-7a22-9b41c91796f8@intel.com> <43fec733ea5331c6de4592dbf44a62e0c61eecb1.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43fec733ea5331c6de4592dbf44a62e0c61eecb1.camel@intel.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E6FD54000F X-Stat-Signature: rns6heze4xga1pgfoy3g9ro34f8w8hbb X-HE-Tag: 1676390813-405752 X-HE-Meta: U2FsdGVkX1/iNTJhLnjnrMQdEbTMTOqGtNpcWDkJd+/Z8F7/D11mHMLv3y4u+JpM/JXMo9XmAbBzRwwEnk8QsT78R2uQhI52yVK5HkWkwuVeakHRNUsjUOxdjPYM/9oiZ5Go0snGNO8T2zTqjEGneEOEM32wRzAFM571wX2jvw7GmxmU0+D97ERUuVjWNUG1XjtZr1sw+wxdZJkN/F2PGuHh/09MOqRrTDCqcHIhCdUNhh9n9O3uMO7fGnaux9MLjNg0EfDSj5lc8NY9jPhNnWGKFU3kIqL4srLFZrOnaTds1YvYQbJoiOJoG/vSvCDmwyLQkgnuc52/AtA8a5+ZVJ22IZNXcsVRU8LyOG13KgyS4GhZrnoJTNRj7am5puW4fs1JrtaRhA+IEwW4IUYQqvzfXL4GkaiKc/Z3vB56yOYCxdFZtPwqzA6oH3O7Eu2OipebUHj3rLLelp7ZJ0/DBjMysJvRrpKnbAvRZ2h48hLbfQr5kn2hFZbxkdEdagJWDk+Et7FIWb0UTQOFlKWoOEJg8tUaglCjh5ZGbhuiJIbIl3f2uoIZ9c+OM7dNTdhIMY/v7cOB7U9cEslYV1gcSK4KngcuRYOkz89kGN8aZZP6DglLLopDxr8ITmFSyYGyOamXHjw09eXdOUfnzmcAd3b7MIDrvOiOto5xj0u9LJE/UL8jIEj5+URJV1ZoveXO+ISV9Ru5Xm1gJddHxn4hv9APRzh59N2VJ2dAL73y9RBjSJRMUI2WVHtGoIPoui+cIL+NHFFNoidwWBq0+rBLFSjhbCeu4b6SNw/M35UvwXMeZNAO4+XBYVJGOQa5Of4zP+NxEC4MHv5P2n+TeGOUYyR0ZW6pbG3H0EPZCUDm/1tFmtnJEDuuTlXAhYNP++p2Z68FgkGMXsfmj4my+WZZJiXuj4rtmZrEMPLcWtfB3496SUPxfDhtBMOnwDgwFht+cri3ENV5U/HX2DE2B6+ NDrMg5Yv f69TL/aBQPUEaS9VebH91mUBsojhKTE6hkJAhuNh8CgZ/3JTdhJ/hLouFtdz8NmUnCOTxHvafeXkcHLsdwartXN/SSUfj2Vk1TfQPvcVIfgUuS/Tv560PJz6UkVC6WU2+VkCsZVlE5GeXDMCLOFmwFu/gbZkLLgshA24CWTixNVA1MXSu9PwJL61pRrxsYW8NWRQJfgE9vgt7uTPdMCX/Cn5PMrADGdcWNCyXqSS6sz+gSShOwOweeoxSBI+28SyIaqvRHI4Ksr9QFBWlYaW2rjLJPHGJM9YpoDncDUXpM0yN8Mv+sQ3c8XbhTg== 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: On Tue, Feb 14, 2023 at 12:02:22AM +0000, Huang, Kai wrote: > On Mon, 2023-02-13 at 14:43 -0800, Dave Hansen wrote: > > On 2/13/23 13:19, Huang, Kai wrote: > > > > On 2/13/23 03:59, Kai Huang wrote: > > > > > To avoid duplicated code, add a > > > > > helper to call SEAMCALL on all online cpus one by one but with a skip > > > > > function to check whether to skip certain cpus, and use that helper to > > > > > do the per-cpu initialization. > > > > ... > > > > > +/* > > > > > + * Call @func on all online cpus one by one but skip those cpus > > > > > + * when @skip_func is valid and returns true for them. > > > > > + */ > > > > > +static int tdx_on_each_cpu_cond(int (*func)(void *), void *func_data, > > > > > + bool (*skip_func)(int cpu, void *), > > > > > + void *skip_data) > > > > I only see one caller of this. Where is the duplicated code? > > > The other caller is in patch 15 (x86/virt/tdx: Configure global KeyID on all packages). > > > > > > I kinda mentioned this in the changelog: > > > > > > " Similar to the per-cpu module initialization, a later step to config the key for the global KeyID..." > > > > > > If we don't have this helper, then we can end up with having below loop in two functions: > > > > > > for_each_online(cpu) { > > > if (should_skip(cpu)) > > > continue; > > > > > > // call @func on @cpu. > > > } > > > > I don't think saving two lines of actual code is worth the opacity that > > results from this abstraction. > > Alright thanks for the suggestion. I'll remove this tdx_on_each_cpu_cond() and > do directly. > > But just checking: > > LP.INIT can actually be called in parallel on different cpus (doesn't have to, > of course), so we can actually just use on_each_cpu_cond() for LP.INIT: > > on_each_cpu_cond(should_skip_cpu, smp_func_module_lp_init, NULL, true); > > But IIUC Peter doesn't like using IPI and prefers using via work: > > https://lore.kernel.org/lkml/Y30dujuXC8wlLwoQ@hirez.programming.kicks-ass.net/ > > So I used smp_call_on_cpu() here, which only calls @func on one cpu, but not a > cpumask. For LP.INIT ideally we can have something like: > > schedule_on_cpu(struct cpumask *cpus, work_func_t func); > > to call @func on a cpu set, but that doesn't exist now, and I don't think it's > worth to introduce it? schedule_on_each_cpu() exists and can easily be extended to take a cond function if you so please.