From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mx.groups.io with SMTP id smtpd.web11.7855.1676009136640824231 for ; Thu, 09 Feb 2023 22:05:36 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="unable to parse pub key" header.i=@intel.com header.s=intel header.b=m9n8og5w; spf=pass (domain: intel.com, ip: 192.55.52.151, 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=1676009136; x=1707545136; h=from:to:subject:date:message-id; bh=PMwS5Tu0Qe8GF32+U3QvS4UCaUwNFDSqZQUe5faZJos=; b=m9n8og5wQM7CEO2vxHAZcgizfnnhAETkFT5MczaV51Qhpqm4OrNz7ecS IJwITJcu7OsPEfttZ7igLJky6gXR49S4feg+yhx3fIWoueb5x1ATyv6qL Y6tbEGbN+SJ6eizjHJdnFipJ24ZVgeww52TXGoT9gjsSU7FI42swtkWt6 oE7HofEVZGT42sggUZ1ynTwrVUooGe/U99xQkqwZ4lBFuZyYMpzJBq18z RifQMXAqOPOn0d6g/kBW33UA457Z8luUcYT85ENy2J7ssaG2KYp02wng5 fitT7Nq8rjQkV0tNihIuIsE2c7J5ngbVelTHda9p6JrHCYUCkWpN71cAI Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10616"; a="310711756" X-IronPort-AV: E=Sophos;i="5.97,286,1669104000"; d="scan'208";a="310711756" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2023 22:05:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10616"; a="791854661" X-IronPort-AV: E=Sophos;i="5.97,286,1669104000"; d="scan'208";a="791854661" Received: from sh1gapp1009.ccr.corp.intel.com ([10.239.189.79]) by orsmga004.jf.intel.com with ESMTP; 09 Feb 2023 22:05:28 -0800 From: "Wu, Jiaxin" To: devel@edk2.groups.io Subject: [PATCH v4 0/5] Simplify SMM Relocation Process Date: Fri, 10 Feb 2023 14:05:14 +0800 Message-Id: <20230210060519.11100-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. Jiaxin Wu (5): UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call 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 | 8 + .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 4 + UefiCpuPkg/Include/Guid/SmmBaseHob.h | 64 +++++++ .../Library/SmmCpuFeaturesLib/CpuFeaturesLib.h | 2 + .../SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c | 23 ++- .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 4 + .../SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf | 1 + UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c | 1 - .../StandaloneMmCpuFeaturesLib.inf | 4 + UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 29 +++- UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 23 +++ UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 191 ++++++++++++++++----- UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 24 +++ UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 1 + UefiCpuPkg/UefiCpuPkg.dec | 3 + 15 files changed, 332 insertions(+), 50 deletions(-) create mode 100644 UefiCpuPkg/Include/Guid/SmmBaseHob.h -- 2.16.2.windows.1