From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 C8A6D21143008 for ; Tue, 18 Sep 2018 19:15:34 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 19:15:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,392,1531810800"; d="scan'208";a="92950189" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.8]) ([10.239.9.8]) by orsmga002.jf.intel.com with ESMTP; 18 Sep 2018 19:15:32 -0700 To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Vincent Zimmer , Brian Richardson , Michael D Kinney , Andrew Fish , Leif Lindholm , Star Zeng , Eric Dong , Liming Gao , Jaben Carsey , Steven Shi References: <20180915132859.25727-1-ard.biesheuvel@linaro.org> <20180915132859.25727-8-ard.biesheuvel@linaro.org> <286cf4b7-853d-8dcf-f519-46db5359c851@Intel.com> From: "Ni, Ruiyu" Message-ID: <97d3d3c0-8aba-e1d6-a082-e7b9ddcd9beb@Intel.com> Date: Wed, 19 Sep 2018 10:16:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH v2 7/7] MdeModulePkg/DxeCore: remove explicit EBC handling 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: Wed, 19 Sep 2018 02:15:35 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 9/18/2018 9:47 PM, Ard Biesheuvel wrote: > On 18 September 2018 at 02:05, Ni, Ruiyu wrote: >> On 9/15/2018 9:28 PM, Ard Biesheuvel wrote: >>> >>> Now that the EBC machine type is no longer classified as a >>> natively supported machine type on the architectures that can >>> support it via the EBC interpreter, the EBC specific handling >>> in DXE core is no longer used and can be removed. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ard Biesheuvel >>> --- >>> MdeModulePkg/Core/Dxe/DxeMain.h | 3 -- >>> MdeModulePkg/Core/Dxe/DxeMain.inf | 1 - >>> MdeModulePkg/Core/Dxe/Image/Image.c | 53 ++------------------ >>> 3 files changed, 3 insertions(+), 54 deletions(-) >>> >>> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h >>> b/MdeModulePkg/Core/Dxe/DxeMain.h >>> index ff2418c5ae5e..c473006813fe 100644 >>> --- a/MdeModulePkg/Core/Dxe/DxeMain.h >>> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h >>> @@ -42,7 +42,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, >>> EITHER EXPRESS OR IMPLIED. >>> #include >>> #include >>> #include >>> -#include >>> #include >>> #include >>> #include >>> @@ -228,8 +227,6 @@ typedef struct { >>> BASE_LIBRARY_JUMP_BUFFER *JumpContext; >>> /// Machine type from PE image >>> UINT16 Machine; >>> - /// EBC Protocol pointer >>> - EFI_EBC_PROTOCOL *Ebc; >>> /// PE/COFF Image Emulator Protocol pointer >>> EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL *PeCoffEmu; >>> /// Runtime image list >>> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf >>> b/MdeModulePkg/Core/Dxe/DxeMain.inf >>> index 63e650ee7c27..a969b869b331 100644 >>> --- a/MdeModulePkg/Core/Dxe/DxeMain.inf >>> +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf >>> @@ -161,7 +161,6 @@ >>> gEfiLoadedImageProtocolGuid ## PRODUCES >>> gEfiLoadedImageDevicePathProtocolGuid ## PRODUCES >>> gEfiHiiPackageListProtocolGuid ## SOMETIMES_PRODUCES >>> - gEfiEbcProtocolGuid ## SOMETIMES_CONSUMES >>> gEfiSmmBase2ProtocolGuid ## SOMETIMES_CONSUMES >>> gEfiBlockIoProtocolGuid ## SOMETIMES_CONSUMES >>> gEdkiiPeCoffImageEmulatorProtocolGuid ## SOMETIMES_CONSUMES >>> diff --git a/MdeModulePkg/Core/Dxe/Image/Image.c >>> b/MdeModulePkg/Core/Dxe/Image/Image.c >>> index 0a4bb3644af0..902a44455fdd 100644 >>> --- a/MdeModulePkg/Core/Dxe/Image/Image.c >>> +++ b/MdeModulePkg/Core/Dxe/Image/Image.c >>> @@ -66,7 +66,6 @@ LOADED_IMAGE_PRIVATE_DATA mCorePrivateImage = { >>> NULL, // JumpBuffer >>> NULL, // JumpContext >>> 0, // Machine >>> - NULL, // Ebc >>> NULL, // PeCoffEmu >>> NULL, // RuntimeData >>> NULL // LoadedImageDevicePath >>> @@ -83,9 +82,6 @@ typedef struct { >>> CHAR16 *MachineTypeName; >>> } MACHINE_TYPE_INFO; >>> -// >>> -// EBC machine is not listed in this table, because EBC is in the default >>> supported scopes of other machine type. >>> -// >>> GLOBAL_REMOVE_IF_UNREFERENCED MACHINE_TYPE_INFO mMachineTypeInfo[] = { >>> {EFI_IMAGE_MACHINE_IA32, L"IA32"}, >>> {EFI_IMAGE_MACHINE_IA64, L"IA64"}, >>> @@ -705,51 +701,15 @@ CoreLoadPeImage ( >>> InvalidateInstructionCacheRange ((VOID >>> *)(UINTN)Image->ImageContext.ImageAddress, >>> (UINTN)Image->ImageContext.ImageSize); >>> // >>> - // Copy the machine type from the context to the image private data. >>> This >>> - // is needed during image unload to know if we should call an EBC >>> protocol >>> - // to unload the image. >>> + // Copy the machine type from the context to the image private data. >>> // >>> Image->Machine = Image->ImageContext.Machine; >>> // >>> - // Get the image entry point. If it's an EBC image, then call into the >>> - // interpreter to create a thunk for the entry point and use the >>> returned >>> - // value for the entry point. >>> + // Get the image entry point. >>> // >>> Image->EntryPoint = >>> (EFI_IMAGE_ENTRY_POINT)(UINTN)Image->ImageContext.EntryPoint; >>> - if (Image->ImageContext.Machine == EFI_IMAGE_MACHINE_EBC) { >>> - // >>> - // Locate the EBC interpreter protocol >>> - // >>> - Status = CoreLocateProtocol (&gEfiEbcProtocolGuid, NULL, (VOID >>> **)&Image->Ebc); >>> - if (EFI_ERROR(Status) || Image->Ebc == NULL) { >>> - DEBUG ((DEBUG_LOAD | DEBUG_ERROR, "CoreLoadPeImage: There is no EBC >>> interpreter for an EBC image.\n")); >>> - goto Done; >>> - } >>> - >>> - // >>> - // Register a callback for flushing the instruction cache so that >>> created >>> - // thunks can be flushed. >>> - // >>> - Status = Image->Ebc->RegisterICacheFlush (Image->Ebc, >>> (EBC_ICACHE_FLUSH)InvalidateInstructionCacheRange); >>> - if (EFI_ERROR(Status)) { >>> - goto Done; >>> - } >>> - >>> - // >>> - // Create a thunk for the image's entry point. This will be the new >>> - // entry point for the image. >>> - // >>> - Status = Image->Ebc->CreateThunk ( >>> - Image->Ebc, >>> - Image->Handle, >>> - (VOID *)(UINTN) >>> Image->ImageContext.EntryPoint, >>> - (VOID **) &Image->EntryPoint >>> - ); >>> - if (EFI_ERROR(Status)) { >>> - goto Done; >>> - } >>> - } else if (Image->PeCoffEmu != NULL) { >>> + if (Image->PeCoffEmu != NULL) { >>> Status = Image->PeCoffEmu->RegisterImage (Image->PeCoffEmu, >>> Image->ImageBasePage, >>> EFI_PAGES_TO_SIZE >>> (Image->NumberOfPages), >>> @@ -939,13 +899,6 @@ CoreUnloadAndCloseImage ( >>> UnprotectUefiImage (&Image->Info, Image->LoadedImageDevicePath); >>> - if (Image->Ebc != NULL) { >>> - // >>> - // If EBC protocol exists we must perform cleanups for this image. >>> - // >>> - Image->Ebc->UnloadImage (Image->Ebc, Image->Handle); >>> - } >>> - >>> if (Image->PeCoffEmu != NULL) { >>> // >>> // If the PE/COFF Emulator protocol exists we must unregister the >>> image. >>> >> >> Ard, >> Does this change mean EBC and x86 won't be enabled together? >> > > I am not sure I understand your question, so let me just explain again > what the purpose is of this patch. > > In the preceding patches, the EBC driver is updated so it implements > the PE/COFF emulator protocol, which is a more generic way of exposing > emulator/interpreter functionality to other modules, and the DXE core > and UefiBaseTypes.h are updated so that EBC modules will be handled > using this new protocol (PE/COFF images that we not built for the > native architecture are handed to each existing instance of the > PE/COFF emulator protocol until one is found that supports it). > > This means the explicit EBC handling is new dead code, so it can be removed. I can understand till now. > > On AARCH64 with the X86 emulator installed, EBC and X86 PE/COFF images > can both be dispatched. The X86 emulator contains code only supporting interpreting X86 machine code. Why EBC images can be dispatched with the help from X86 emulator? On builds with only the EBC driver installed > (AARCH64 or otherwise), only EBC images and native images can be > executed. > > I hope this answers your question. > -- Thanks, Ray