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 21C5CEB64DD for ; Tue, 27 Jun 2023 12:19:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E0DE8D0002; Tue, 27 Jun 2023 08:19:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76AA78D0001; Tue, 27 Jun 2023 08:19:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E37A8D0002; Tue, 27 Jun 2023 08:19:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4B3A88D0001 for ; Tue, 27 Jun 2023 08:19:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F3C971C8264 for ; Tue, 27 Jun 2023 12:19:08 +0000 (UTC) X-FDA: 80948432376.03.06C068E Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf17.hostedemail.com (Postfix) with ESMTP id 13C7940018 for ; Tue, 27 Jun 2023 12:19:05 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Q1SvuTSX; spf=none (imf17.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687868346; a=rsa-sha256; cv=none; b=ZQaHPx2BacJvr45swvQZOrYDx4uUQNxygNR08v2jUgsJER5iEUtZRmkX9DvcCw8JBkb5ZH JEV+r0PqOzKte8NIPwDXp3ZOgTETeToPybB9mdg/gyUhdwbt2ViKSVRfTHpzuxwhB4nSE8 s8OL2ahXh3f3Q77DZtuI4Kraa2aHpTQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Q1SvuTSX; spf=none (imf17.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=kirill.shutemov@linux.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=1687868346; 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=wK7yA0pjmYWcR0GdJVJojbTZ/AohDP7swFuJRA53W3w=; b=fypX7nAqi8Oc3DB4hGW38/O4NsgEg1BpS6v2OMn+D2FddVRR2apzW2juvA11DXdbtKhucm gZcHRQMW4faVfaqjV7WRWMOp+fzMSSJ7dc4aF8VSMwtktgew7660V9HOPOwL0d7udZYlvv 7oU3tyR7/uYYw5KIf3cGBgyZo5bZu6A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687868346; x=1719404346; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=S/Oh83wIoz8iTjgXyFj7FBvLQ6z/1uq7Rt97/C+Sd54=; b=Q1SvuTSXKQnOXxOUbX+eZq2ZknFKONhpIniRTMMXywzCsh0qlr/GjWk+ YPfCF5Ff+8nmXX4TKF4vhmSt7mwLL2gAIOvOHYI3zLfSx8919Ur65DXWd 2B45+Ip7Tnvn9FTPEJ3tDG7Q9oWSRcIVZTU90edkol1sFhuO+kIBeqP7e dMMCr5FB0Ev2cqY2HDwqH9kswho0jhVCebbZNB0J/ML0hFpeitYE8iKH+ qJcCsUkPa9H9nI2gDzCPax8ilVhzA7YlxbPyk6Z+dzBS9JQ3GXDo4ZLXb f9DKWL9RTkhQnnBZUX9FO9vh/+1geiRNMeuccs1aMhsH/YB/m38tC1LOG g==; X-IronPort-AV: E=McAfee;i="6600,9927,10753"; a="364105349" X-IronPort-AV: E=Sophos;i="6.01,162,1684825200"; d="scan'208";a="364105349" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2023 05:19:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10753"; a="963174691" X-IronPort-AV: E=Sophos;i="6.01,162,1684825200"; d="scan'208";a="963174691" Received: from rbhaumik-mobl2.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.217.121]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2023 05:18:56 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 453D0103738; Tue, 27 Jun 2023 15:18:53 +0300 (+03) Date: Tue, 27 Jun 2023 15:18:53 +0300 From: "kirill.shutemov@linux.intel.com" To: "Huang, Kai" Cc: "kvm@vger.kernel.org" , "Raj, Ashok" , "Hansen, Dave" , "david@redhat.com" , "bagasdotme@gmail.com" , "Luck, Tony" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Christopherson,, Sean" , "mingo@redhat.com" , "pbonzini@redhat.com" , "linux-mm@kvack.org" , "tglx@linutronix.de" , "Yamahata, Isaku" , "Chatre, Reinette" , "nik.borisov@suse.com" , "hpa@zytor.com" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "bp@alien8.de" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "x86@kernel.org" , "Williams, Dan J" Subject: Re: [PATCH v12 07/22] x86/virt/tdx: Add skeleton to enable TDX on demand Message-ID: <20230627121853.ek5zr7sfiezfkfyj@box.shutemov.name> References: <104d324cd68b12e14722ee5d85a660cccccd8892.1687784645.git.kai.huang@intel.com> <20230627095012.ln47s62pqzdrnb7x@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 13C7940018 X-Stat-Signature: scfy1qiqor8pmebjpfpk5co4sneikmjw X-Rspam-User: X-HE-Tag: 1687868345-45912 X-HE-Meta: U2FsdGVkX19+AptudtIfNua5r6/tH1kco9NHcvxqtPsEKjA0zJH2xlMNnDarv/oja4TCZh5Of/WfMcDL68mcHCnY4deo62GINsl+p31Nl5mQNwBsZLGngE6rdrocHB/aowL9IgNC+raLXRRVZ92AKA/tPO+a2oSslP5hmvx8JjO+aoqT57sLN6u1iQZlLe0oLLJOySoElFmx9kjR3IJjWzfEklAk3MtcUW0dh9n2yp9bPdwC1FxccDLmkq1CCsIKZVhbWw0J4TE6q7FNdzaZDPGxS6909njgrRqbZem0YnsmmFbfGqhdenIouNpc6E9Add/eLtP2x305YgYNSAERbjhTRpt/vte079a6hyQM6n0Jpa4Jej207X9o006zM2ZzbBWudTqzp5vkIvJqC2UCj33Ts34pDOKmUjxuTqnFrss23yWjaXVTcp7LAKcHvdmVuoW1kvIwdxoYkeaHc88uByZY6m4Ww1GBQW085415NB0s/kz7YqH5yYG0ymjHjynjuGTHo9dbAKOMV4vp2d6cJhNC2Simbs8rH1btO5Gk5D8nNwgZ4NVandkoVSxXQ0HXibBqr3WilLo7gSsNXM0XCEOjW95Qy2v4ULRF8qIKxHcSOjLf9TiCjVxg0Zh2n37on78RjBeqvUU2Y/7UZbA+FQhW3weyF5BSZV8+BLlLK2ZNzQLzHToWE79vkLjcBg+R2K+sakkh3jcfPNzZLKgO/kkd1Lt6wSUBR9vR9wXA7fu9tBX+2mn+LoNrqffBlgJ/qigI6SrvIkhbZTCUjfvyse0Zq60hepKSLpyc0TVR9yC+4kl78VOBFmK5PGtXVjpdFnJOz7AIJJ3f8OJiLBEQwU5IUKj6Vgx56fTGawrHMIyJ+aNnlZedWEh0/nMZ3ftbUYkf5bN8fDgyIicIclO1qG8yHax710GEKGXEaAk1Z5AxAgycoB+75O3nmvV4j4/Oa/+RoWkIePcHr0fR9Bj voYRi2A1 GN9Tz0jbEsd12WIF72qMl3r84UKWqE1xcHkyscgj46gbbs/qpX6v3xSf5YMxhe5xjfH+5SQCLrXrV5cg4783rzkEcGNI2LzY7PrBBHbkqSfrJzpTa4TLZFkmPX6ZhWlkcD/mun2Gr9luDmPXYLlx/l/V+7RPrw2UbuO9Fjm7kfx/so3vL2jtcXLp8v4ILMO0Y0gcH9Vr0lAgvJJ+f81cthplDJl6eJsU2+r+GMQ8X9k4T9EiNx5+NwTENCw== 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, Jun 27, 2023 at 10:34:04AM +0000, Huang, Kai wrote: > On Tue, 2023-06-27 at 12:50 +0300, kirill.shutemov@linux.intel.com wrote: > > On Tue, Jun 27, 2023 at 02:12:37AM +1200, Kai Huang wrote: > > > + /* > > > + * The TDX module global initialization only needs to be done > > > + * once on any cpu. > > > + */ > > > + raw_spin_lock_irqsave(&tdx_global_init_lock, flags); > > > > I don't understand how the comment justifies using raw spin lock. > > > > This comment is for using lock in general. The reason to use raw_ version is > because this function gets called in IRQ context, and for PREEMPT_RT kernel the > normal spinlock is converted to sleeping lock. Sorry, but this still doesn't explain anything. Why converting to sleeping lock here is wrong? There are plenty spin_lock_irqsave() users all over the kernel that are fine to be converted to sleeping lock on RT kernel. Why this use-case is special enough to justify raw_? >From the documentation: raw_spinlock_t is a strict spinning lock implementation in all kernels, including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical core code, low-level interrupt handling and places where disabling preemption or interrupts is required, for example, to safely access hardware state. raw_spinlock_t can sometimes also be used when the critical section is tiny, thus avoiding RT-mutex overhead. How does it apply here? > Dave suggested to comment on the function rather than comment on the > raw_spin_lock directly, e.g., no other kernel code does that: > > https://lore.kernel.org/linux-mm/d2b3bc5e-1371-0c50-8ecb-64fc70917d42@intel.com/ > > So I commented the function in this version: > > +/* > + * Do the module global initialization if not done yet. > + * It's always called with interrupts and preemption disabled. > + */ If interrupts are always disabled why do you need _irqsave()? -- Kiryl Shutsemau / Kirill A. Shutemov