From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.23204.1675258859590963728 for ; Wed, 01 Feb 2023 05:40:59 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OK32xdDp; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675258858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bsGfaAJgImzLCRUVSUsPVitRgB+wng0f9lfty9SJ63Q=; b=OK32xdDpOZMAUGDRm1tJQdqcAY7nM31hedcM90AlBjLkXWk7RHVhjhmQnjYg/Gb/+ol91r rfhmrFzcPhy1DChK1rvcEpPADZ/ru1CZ5/nEGnOttQWgvOs8r697NPI3irSsdTs/7zXJVB ZYB5TTHH7vs8thvWXpUvBpCKC1yyVKE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-140-AJ5ZpdZINPKGhq7XpIgy9w-1; Wed, 01 Feb 2023 08:40:53 -0500 X-MC-Unique: AJ5ZpdZINPKGhq7XpIgy9w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AA77B3848C23; Wed, 1 Feb 2023 13:40:52 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7D41FC15BAE; Wed, 1 Feb 2023 13:40:52 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 33CF618000A9; Wed, 1 Feb 2023 14:40:51 +0100 (CET) Date: Wed, 1 Feb 2023 14:40:51 +0100 From: "Gerd Hoffmann" To: "Wu, Jiaxin" Cc: "Ni, Ray" , "devel@edk2.groups.io" , "Dong, Eric" , "Zeng, Star" , Laszlo Ersek , "Kumar, Rahul R" Subject: Re: [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration Message-ID: <20230201134051.7jlc7a74cogcskw5@sirius.home.kraxel.org> References: <20230118095620.9860-1-jiaxin.wu@intel.com> <20230118095620.9860-6-jiaxin.wu@intel.com> <20230118121958.cxbfh3fljedvebis@sirius.home.kraxel.org> <20230119075303.nkyno36h25xscwkn@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 29, 2023 at 05:47:00AM +0000, Wu, Jiaxin wrote: > > > > * Why do you want do it in PEI instead? The cover letter claims this > > improves boot performance. I don't buy that. You are not skipping > > the relocation process, you are just doing it somewhere else. > > I clarified why it can improves boot performance, it's not just do > somewhere else, but also each cpus smbase can be programmed in > parallel. See [PATCH v3 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM > Base Hob for SmBase info: Current state: * PiSmmCpuDxeSmm does SMM initialization, including programming SMBASE, serialized. With this series applied: * Some PEI module programs SMBASE, serialized. * PiSmmCpuDxeSmm does SMM initialization, but NOT programming SMBASE, in parallel. Sure PiSmmCpuDxeSmm alone will run faster because it can run parallel now. But the serialized SMBASE programming still happens, now in the PEI module, and I don't see a good reason why the runtime the new PEI module and the runtime of PiSmmCpuDxeSmm combined is faster than before. > > * Where is the code? > See the design of existing function: SemaphoreHook (Index, &mRebased[Index]); I mean the PEI module code. > > * It is totally unclear whenever it is possible and/or useful to > > initialize SMM that way on OVMF. > Add the same handing logic code in OVMF is necessary to make sure it > work. If someone produced such hob in OVMF platform, Do you intent submitting code for OVMF producing such a HOB? There isn't any in this series. > Changes in OVMF is make sure it runs into right way. As it stands you are only adding dead code for no reason. How is the SMM initialization of hotplugged CPUs supposed to work with the new mode of operation? take care, Gerd