From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.115; helo=mga14.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 19B772117D267 for ; Sun, 28 Oct 2018 20:04:26 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2018 20:04:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,438,1534834800"; d="scan'208";a="85224243" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.11]) ([10.239.9.11]) by orsmga008.jf.intel.com with ESMTP; 28 Oct 2018 20:04:24 -0700 To: Jian J Wang , edk2-devel@lists.01.org Cc: Eric Dong , Laszlo Ersek , Jiewen Yao , Star Zeng References: <20181026124056.6052-1-jian.j.wang@intel.com> From: "Ni, Ruiyu" Message-ID: <6314edec-6c57-2e98-3481-3799da306499@Intel.com> Date: Mon, 29 Oct 2018 11:05:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181026124056.6052-1-jian.j.wang@intel.com> Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: optimize TLB flush operation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 03:04:27 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/26/2018 8:40 PM, Jian J Wang wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1281 > > This optimization has two purpose: > > 1. fix BZ#1281 which caused by flushing TLB for AP > 2. improve performance for SMM heap guard > > The code change is simple: just flush TLB for current processor. > > Since processor's (including AP) SMI entry code will always initialize > CR3, it looks like that there's no need to add extra code in AP handler, > called from SMI entry, to flush TLB again. > > Let each processor itself guarantee the TLB integrity can improve memory > operations performance if Heap Guard is enabled. This has been proved > by CpuDxe driver. Please check following patches for details. > > 41a9c3fd110bed93c4fdf088eea18412bb2dfcde > 0dbb0f1a5ce6a9ec5213c85e5d4244cf5b061417 > Stop flush TLB for APs (DXE) upon change > > 199de89677deffffff30eda7ad17793b30042cce > Let AP (DXE) flush TLB in its wake-up procedure > > Tests: > a. Verified that issue in BZ#1281 is gone > b. Verified SMM heap guard works well on any processor > c. OVMF boot (Fedora26, Ubuntu18.04, Windows 10) > > Cc: Eric Dong > Cc: Laszlo Ersek > Cc: Jiewen Yao > Cc: Star Zeng > Cc: Ruiyu Ni > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jian J Wang > --- > UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 45 +++------------------- > 1 file changed, 6 insertions(+), 39 deletions(-) > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c > index 684b14dc28..e0bf0cd5ac 100644 > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c > @@ -464,41 +464,6 @@ ConvertMemoryPageAttributes ( > return RETURN_SUCCESS; > } > > -/** > - FlushTlb on current processor. > - > - @param[in,out] Buffer Pointer to private data buffer. > -**/ > -VOID > -EFIAPI > -FlushTlbOnCurrentProcessor ( > - IN OUT VOID *Buffer > - ) > -{ > - CpuFlushTlb (); > -} > - > -/** > - FlushTlb for all processors. > -**/ > -VOID > -FlushTlbForAll ( > - VOID > - ) > -{ > - UINTN Index; > - > - FlushTlbOnCurrentProcessor (NULL); > - > - for (Index = 0; Index < gSmst->NumberOfCpus; Index++) { > - if (Index != gSmst->CurrentlyExecutingCpu) { > - // Force to start up AP in blocking mode, > - SmmBlockingStartupThisAp (FlushTlbOnCurrentProcessor, Index, NULL); > - // Do not check return status, because AP might not be present in some corner cases. > - } > - } > -} > - > /** > This function sets the attributes for the memory region specified by BaseAddress and > Length from their current attributes to the attributes specified by Attributes. > @@ -538,9 +503,10 @@ SmmSetMemoryAttributesEx ( > if (!EFI_ERROR(Status)) { > if (IsModified) { > // > - // Flush TLB as last step > + // Flush TLB as last step. No need to do it for APs, which sould take care > + // of it in the wake-up procedure. > // > - FlushTlbForAll(); > + CpuFlushTlb (); > } > } > > @@ -586,9 +552,10 @@ SmmClearMemoryAttributesEx ( > if (!EFI_ERROR(Status)) { > if (IsModified) { > // > - // Flush TLB as last step > + // Flush TLB as last step. No need to do it for APs, which sould take care > + // of it in the wake-up procedure. > // > - FlushTlbForAll(); > + CpuFlushTlb (); > } > } > > Jian, I see you are using the same optimization as that in DXE MP to improve performance. But considering AP already runs to ApHandler() when BSP calls SmmStartupAp(), this optimization cannot be used actually. The original code is safe. With your changes, the AP's TLB is not flushed and may use out-of-date page table settings. I think for the specific Bugzilla, it's caller's fault to use the wrong DebugLib instance. AP procedure shouldn't call any PI/UEFI interface. We do not need to fix it. -- Thanks, Ray