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.151; helo=mga17.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 0EEA32112944B for ; Sun, 16 Sep 2018 21:03:17 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Sep 2018 21:03:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,384,1531810800"; d="scan'208";a="73543415" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga007.jf.intel.com with ESMTP; 16 Sep 2018 21:03:01 -0700 Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 16 Sep 2018 21:03:01 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.72]) by ORSMSX111.amr.corp.intel.com ([169.254.12.139]) with mapi id 14.03.0319.002; Sun, 16 Sep 2018 21:03:01 -0700 From: "Kinney, Michael D" To: Ard Biesheuvel , "Kinney, Michael D" CC: "Ni, Ruiyu" , "Zimmer, Vincent" , "Dong, Eric" , "edk2-devel@lists.01.org" , Andrew Fish , "agraf@suse.de" , "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///kB0IADW52AgAIQJMA= Date: Mon, 17 Sep 2018 04:03:00 +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.140] 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: Mon, 17 Sep 2018 04:03:18 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ard, I look forward to discussing this in more detail this week. We can update this thread with that information. Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] > On Behalf Of Ard Biesheuvel > Sent: Saturday, September 15, 2018 6:28 AM > To: Kinney, Michael D > Cc: Ni, Ruiyu ; Zimmer, Vincent > ; Dong, Eric > ; edk2-devel@lists.01.org; Andrew > Fish ; agraf@suse.de; Richardson, Brian > ; Laszlo Ersek > ; Zeng, Star > Subject: Re: [edk2] [PATCH 0/4] MdeModulePkg: add support > for dispatching foreign arch PE/COFF images >=20 > On 13 September 2018 at 19:20, Kinney, Michael D > wrote: > > Ard, > > > > I think there is a fundamental assumption that > > the sizeof(UINTN) and size of pointers of > > 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. > > >=20 > There is no such assumption. The PE/COFF emulator protocol > is an > abstract protocol that leaves it fully up to the > implementation to > decide whether it can support images of machine type X and > image type > Y. >=20 > > Protocols that only allow a single instance need to > > clearly document that assumption. > > >=20 > I will remove that restriction. >=20 > > 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 > > 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. > > >=20 > Yes, excellent idea, and it results in a nice cleanup as > well >=20 > > 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 > > paging enabled and the EBC interpreter work without > > 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. > > >=20 > The paging disabled case is interesting. Does the UEFI > spec even > permit running in DXE with paging disabled? >=20 > In any case, I will send out a v2 as the basis for further > discussion. > We can also sit down and discuss it in Vancouver the > coming week. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel