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.100; helo=mga07.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 262BD21B02822 for ; Thu, 13 Sep 2018 10:22:34 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 10:22:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,369,1531810800"; d="scan'208";a="70621247" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga008.fm.intel.com with ESMTP; 13 Sep 2018 10:20:26 -0700 Received: from orsmsx157.amr.corp.intel.com (10.22.240.23) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 13 Sep 2018 10:20:26 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.72]) by ORSMSX157.amr.corp.intel.com ([169.254.9.29]) with mapi id 14.03.0319.002; Thu, 13 Sep 2018 10:20:25 -0700 From: "Kinney, Michael D" To: Ard Biesheuvel , "Kinney, Michael D" CC: "Ni, Ruiyu" , "Zimmer, Vincent" , "Dong, Eric" , "edk2-devel@lists.01.org" , "agraf@suse.de" , Andrew Fish , "Richardson, Brian" , Laszlo Ersek , "Zeng, Star" Thread-Topic: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching foreign arch PE/COFF images Thread-Index: AQHUSpuyON64A63PaUSuwR7hF0LO1aTsvukwgAG8fYD///kB0A== Date: Thu, 13 Sep 2018 17:20:25 +0000 Message-ID: References: <20180912132151.4258-1-ard.biesheuvel@linaro.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: [PATCH 0/4] MdeModulePkg: add support for dispatching foreign arch PE/COFF images 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: Thu, 13 Sep 2018 17:22:34 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ard, I think there is a fundamental assumption that the sizeof(UINTN) and size of pointers of=20 the native CPU are the same as the emulated CPU. If that is not the case, then I would like to see more details. Otherwise that is a significant restriction that needs to be clearly documented. Protocols that only allow a single instance need to clearly document that assumption. If we decide to treat EBC as an emulated CPU, then we would want to support multiple instances of the protocol. The updates to the DXE Core are a bit=20 confusing because it has separate handling of EBC and emulated CPUs. I think it would make the DXE Core logic simpler and easier to understand if they were combined. I asked about the startup case because if we do EBC, then we may need more services in the protocol because of the thunk code between native and EBC code. At the time EBC was originally implemented, we did not have=20 paging enabled and the EBC interpreter work without=20 depending on a page fault handler. The way the protocol is currently defined, I believe it fundamentally assumes paging is enabled. If paging is not enabled, then the current protocol services are not sufficient for any emulated CPU. Do we want this to work for paging disabled cases? If not, another assumption to clearly document. Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel- > bounces@lists.01.org] On Behalf Of Ard Biesheuvel > Sent: Thursday, September 13, 2018 3:37 AM > To: Kinney, Michael D > Cc: Ni, Ruiyu ; Zimmer, Vincent > ; Dong, Eric > ; edk2-devel@lists.01.org; > agraf@suse.de; Andrew Fish ; > Richardson, Brian ; Laszlo > Ersek ; Zeng, Star > > Subject: Re: [edk2] [PATCH 0/4] MdeModulePkg: add > support for dispatching foreign arch PE/COFF images >=20 > On 12 September 2018 at 17:10, Kinney, Michael D > wrote: > > Ard, > > > > I think there may be a lot of assumptions in this > > proposal that are not documented. > > > > I do not see any description of how an image is > > started or how calls between native code and emulated > > code are handled. > > >=20 > It is the job of the implementation of the emulator to > use the > information provided to it at registration time to > ensure that calls > to its entry point are handled. One way could be to > remap the code > region non-exec (which is what X86EmulatorPkg does) and > hook the > exceptions that result when calling into the non-native > code. Another > approach could be to do binary translation at load time, > hook the > PE/COFF entry point in the header to point to a load > stub etc etc. >=20 > These are all implementation details of the emulator, > and so I am not > sure what exactly we need to document at the protocol > level. Does the > above paragraph capture more or less what you mean? >=20 > > Also, are multiple emulated CPUs supported? It looks > > like there can only be one instance of this new > protocol. > > >=20 > Yes. I am not sure what the added value is of having > multiple > emulators. Do you have anything in mind? >=20 > In any case, the singleton protocol could be implemented > by a wrapper > driver that encapsulates this multiple dispatch > functionality. I don't > think it makes sense to duplicate logic for that purpose > in the > various places that I touch in this series, and so it > shouldn't affect > the protocol prototypes. >=20 > > Can you please provide more detailed comments for the > > functions in the new protocol and document the > assumptions > > and known limitation in the header? > > >=20 > Of course. But note that they are fairly simple > prototypes that don't > impose any limitations by themselves, other than that > you should call > RegisterImage() before attempting to invoke its entry > point. >=20 > > From one perspective, EBC is an emulated instruction > set. > > Would it make sense to have EBC be one of the emulated > > CPU types that can be plugged in? > > >=20 > We could definitely abstract away the EBC handling in > the DXE core to > be routed via this protocol, but that would make the > changes more > intrusive. I could look into making those changes on top > if there is > interest. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel