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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05797C433EF for ; Tue, 26 Apr 2022 02:12:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241530AbiDZCPR (ORCPT ); Mon, 25 Apr 2022 22:15:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236331AbiDZCPO (ORCPT ); Mon, 25 Apr 2022 22:15:14 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BDF338780; Mon, 25 Apr 2022 19:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650939129; x=1682475129; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=IJj6FwOpcpLQHX+fWpYg9qL+omehrBDi1oT+RhQ57j4=; b=E9GNMQo1bppPBkAt/UYmpf8JLbKrxJFYzkJO/C+Gzc8+1ojyF5Myzebt kw197Dr5Crrmu+33c+pkHERXY/4uWQ++gDPkWL5gPDrOrXTuAPpP1RX5h vKGnnF0hoJL/Mbxwc9/8OWBAjnLJpcd5FhsvfUOlvaxwALCAQFoI0FGGU 4tIpNASZjRg2dQt8+CBWIJDJqNt+ZKB88h7RKVgO6PTZ+r9nERaEq0poq baHflfgyOV8DIiPFHu6bR1jFy/pRXUDzPQX8tbsOX8aJWoPs8IE02m5KC jlAFZWPWDSutO1zx8Z4AXWna2tXN6W/tPhYEyPGbbAvjcI84bnHeexZJp g==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="265587963" X-IronPort-AV: E=Sophos;i="5.90,289,1643702400"; d="scan'208";a="265587963" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 19:12:09 -0700 X-IronPort-AV: E=Sophos;i="5.90,289,1643702400"; d="scan'208";a="616779361" Received: from kculcasi-mobl2.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.59.214]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 19:12:06 -0700 Message-ID: Subject: Re: [PATCH v3 06/21] x86/virt/tdx: Shut down TDX module in case of error From: Kai Huang To: Sathyanarayanan Kuppuswamy , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, len.brown@intel.com, tony.luck@intel.com, rafael.j.wysocki@intel.com, reinette.chatre@intel.com, dan.j.williams@intel.com, peterz@infradead.org, ak@linux.intel.com, kirill.shutemov@linux.intel.com, isaku.yamahata@intel.com Date: Tue, 26 Apr 2022 14:12:04 +1200 In-Reply-To: References: <3f19ac995d184e52107e7117a82376cb7ecb35e7.1649219184.git.kai.huang@intel.com> <82d3cb0b-cebc-d1da-abc1-e802cb8f8ff8@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > Prevent all SEAMCALLs on other LPs except TDH.SYS.LP.SHUTDOWN. The spec defnies > > shutting down the TDX module as running this SEAMCALl on all LPs, so why just > > run on a single cpu? What's the benefit? > > If executing it in one LP prevents SEAMCALLs on all other LPs, I am > trying to understand why spec recommends running it in all LPs? Please see 3.1.2 Intel TDX Module Shutdown and Update The "shutdown" case requires "Execute On" on "Each LP". Also, TDH.SYS.LP.SHUTDOWN describe this is shutdown on *current* LP. > > But the following explanation answers my query. I recommend making a > note about it in commit log or comments. Is above enough to address your question? -- Thanks, -Kai