From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mx.groups.io with SMTP id smtpd.web11.2166.1676363598559087685 for ; Tue, 14 Feb 2023 00:33:18 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=Qgbr8XU8; spf=pass (domain: intel.com, ip: 192.55.52.120, mailfrom: jiaxin.wu@intel.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676363598; x=1707899598; h=from:to:cc:subject:date:message-id; bh=vyrTQjXupma0qrs3z63hsR+pFH5sNtnPkjFGDjeqpc4=; b=Qgbr8XU8EFK3q8Cxj70h8rjrd2thqhe5+BfZUkkSbnR5c2Uuc2IbhpTO p6sLcFqYPcREUAGyqC6zMsm96s1GqwhqYqtMUc8e7VrAvWSx4q2O6jOgt 03jkbdWNc+59PLdwFeTf0sEtaAYMif3hNJ2autYxAzi0VdUj7hAU/0Ruu uUfuppyaCD9VTkMFqKSASkwUrlGL/K+mV8EuwU+M0dJZZ//nOAx2i/WQR NCK/H08SrySFpaDPNutKzPWRUxs79kAIbHSET2mQoNGhQ4KNYg1wwAsYu bpAbu+6vXPF5tTLVYoYa26MQ+MvPWlnAt/4HYhXGQkRVBS0LXeX7DMCrC A==; X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="329736247" X-IronPort-AV: E=Sophos;i="5.97,296,1669104000"; d="scan'208";a="329736247" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2023 00:33:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="914662294" X-IronPort-AV: E=Sophos;i="5.97,296,1669104000"; d="scan'208";a="914662294" Received: from sh1gapp1009.ccr.corp.intel.com ([10.239.189.79]) by fmsmga006.fm.intel.com with ESMTP; 14 Feb 2023 00:33:16 -0800 From: "Wu, Jiaxin" To: devel@edk2.groups.io Cc: Eric Dong , Ray Ni , Zeng Star , Laszlo Ersek , Gerd Hoffmann , Rahul Kumar Subject: [PATCH v7 0/6] Simplify SMM Relocation Process Date: Tue, 14 Feb 2023 16:33:08 +0800 Message-Id: <20230214083314.15092-1-jiaxin.wu@intel.com> X-Mailer: git-send-email 2.16.2.windows.1 Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which will relocate the SMBASE of each processor by setting the SMBASE field in the saved state map (at offset 7EF8h) to a new value. The RSM instruction reloads the internal SMBASE register with the value in SMBASE field when each time it exits SMM. All subsequent SMI requests will use the new SMBASE to find the starting address for the SMI handler (at SMBASE + 8000h). Due to the default SMBASE for all x86 processors is 0x30000, the APs' 1st SMI for rebase has to be executed one by one to avoid the CPUs over-writing each other's SMM Save State Area (see existing SmmRelocateBases() function), which means the next AP has to wait for the previous AP to finish its 1st SMI, then it can call into its 1st SMI for rebase via Smi Ipi command, thus leading the existing SMBASE Relocation has to be running in series. Besides, it needs very complex code to handle the AP exit semaphore (mRebased[Index]), which will hook return address of SMM Save State so that semaphore code can be executed immediately after AP exits SMM for SMBASE relocation (see existing SemaphoreHook() function). This series is to add the new SMM Base HOB for any PEI module to do the SmBase relocation ahead of PiSmmCpuDxeSmm driver and store the relocated SmBase address in array for each Processors. When the SMBASE relocation happens in a PEI module, the PEI module shall produce the SMM_BASE_HOB in HOB database which tells the PiSmmCpuDxeSmm driver (runs at a later phase) about the new SMBASE for each CPU thread. PiSmmCpuDxeSmm driver installs the SMI handler at the SMM_BASE_HOB.SmBase[Index]+0x8000 for CPU thread Index. When the HOB doesn't exist, PiSmmCpuDxeSmm driver shall relocate and program the new SMBASE itself (keep existing SMBASE Relocation way). With SMM Base Hob support, PiSmmCpuDxeSmm does not need the RSM instruction to do the SMBASE Relocation. SMBASE Register for each processors have already been programmed and all SMBASE address have recorded in SMM Base Hob. So the same default SMBASE Address (0x30000) will not be used, thus the CPUs over-writing each other's SMM Save State Area will not happen in PiSmmCpuDxeSmm driver. This way makes the first SMI init can be executed in parallel and save boot time on multi-core system. Besides, Semaphore Hook code logic is also not required, which will greatly simplify the SMBASE Relocation flow. Note: This is the new way that firmware can program the SMBASE independently of the RSM instruction. The PEI code performing this logic will not be open sourced, similarly to other things that are kept binary-only in the FSP. Due to the register difference in different vender, and it has not been documented in the Intel SDM yet, we need a new binary-only interface for SMM Base HOB. Cc: Eric Dong Cc: Ray Ni Cc: Zeng Star Cc: Laszlo Ersek Cc: Gerd Hoffmann Cc: Rahul Kumar Signed-off-by: Jiaxin Wu Jiaxin Wu (6): UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call UefiCpuPkg/PiSmmCpuDxeSmm: Replace mIsBsp by mBspApicId check UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE configuration OvmfPkg/SmmCpuFeaturesLib: Check SmBase relocation supported or not .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 10 +- .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 6 +- UefiCpuPkg/Include/Guid/SmmBaseHob.h | 64 +++++++ .../Library/SmmCpuFeaturesLib/CpuFeaturesLib.h | 2 + .../SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c | 25 ++- .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 6 +- .../SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf | 3 +- UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c | 3 +- .../StandaloneMmCpuFeaturesLib.inf | 6 +- UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 31 +++- UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 25 ++- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 193 ++++++++++++++++----- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 26 ++- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 3 +- UefiCpuPkg/UefiCpuPkg.dec | 5 +- 15 files changed, 345 insertions(+), 63 deletions(-) create mode 100644 UefiCpuPkg/Include/Guid/SmmBaseHob.h -- 2.16.2.windows.1