From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.72; helo=ma1-aaemail-dr-lapp03.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 8E7D221B02822 for ; Wed, 19 Sep 2018 12:35:51 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w8JJXlSb035713; Wed, 19 Sep 2018 12:35:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=z9dvlKUs3K5L7q5JVdELZfdu+YM0hOg0WP32KMuJhAk=; b=UsryQLE2PfQrf1bqXayDR18RTv0S+sAcjVFcoLe618HJHa32wQ47iQYJlusU4045b41G 6kQeuZuhmjhkAnofpM1Gw7rPv2L4ycBpzdPD3p/aCawt+Hh6Lx+jcRkkYs+mfiPH7EvJ RO6FVqRdhD4tZ0p0fxEc1IduXRpTnbMqP8090/QLXHKz8O4nb7d8tRQ9YzCaJOkLx0Or pwjVAhJ9Pt7uSOUh3k1WE+kh2xmTODnyaxVBeJoKAjSzlk+pcD2xU38nwsu3chHIDJrX XZwD19GPpqJwg7g8jrx2f5nDKqagWiIGA6EuxvuIabuUPtEfsgHZbSmcvp7Xad6W4KOA Wg== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2mh1330p53-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 Sep 2018 12:35:49 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PFB000Z6IFN2V00@ma1-mtap-s01.corp.apple.com>; Wed, 19 Sep 2018 12:35:48 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFB00700ICVQV00@nwk-mmpp-sz11.apple.com>; Wed, 19 Sep 2018 12:35:48 -0700 (PDT) X-Va-A: X-Va-T-CD: 6a8fe94fde202cff83873853a5e2c49c X-Va-E-CD: 1ae1132d6484789f3804e4f7f6c18357 X-Va-R-CD: cb92b2f05cb1681df53b8842318af603 X-Va-CD: 0 X-Va-ID: 80fd8e13-e141-45d9-95e8-ddb5c0fdac48 X-V-A: X-V-T-CD: 9b3859669d90162ac484de95f7f3dbd2 X-V-E-CD: 1ae1132d6484789f3804e4f7f6c18357 X-V-R-CD: cb92b2f05cb1681df53b8842318af603 X-V-CD: 0 X-V-ID: 82afa887-7bf0-4bb6-8fe0-fcb195257b8d Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFB00700ID3RO00@nwk-mmpp-sz11.apple.com>; Wed, 19 Sep 2018 12:35:48 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-19_11:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1 Received: from [17.235.3.241] (unknown [17.235.3.241]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PFB0036OIFNM8B0@nwk-mmpp-sz11.apple.com>; Wed, 19 Sep 2018 12:35:48 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Wed, 19 Sep 2018 12:35:36 -0700 Cc: Mike Kinney , "Ni, Ruiyu" , Vincent Zimmer , "Dong, Eric" , "edk2-devel@lists.01.org" , "agraf@suse.de" , "Richardson, Brian" , Laszlo Ersek , "Zeng, Star" Message-id: <158F7824-8679-4121-9E7D-5C3593808909@apple.com> References: <20180912132151.4258-1-ard.biesheuvel@linaro.org> To: Ard Biesheuvel X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-19_11:, , signatures=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: Wed, 19 Sep 2018 19:35:51 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel wrote: > > 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. >> > > 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. > Ard, Not knowing the size of UINTN or a pointer was very painful in terms of how EBC worked. The compiler was forced to generate code for sizeof vs. resolving it at compile time. >> Protocols that only allow a single instance need to >> clearly document that assumption. >> > > I will remove that restriction. > >> 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. >> > > Yes, excellent idea, and it results in a nice cleanup as well > >> 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. >> > > The paging disabled case is interesting. Does the UEFI spec even > permit running in DXE with paging disabled? Paging is a function of the processor binding in the UEFI spec. It is not required for IA32. For X64 you have to have paging enable to enter long mode. On other processors you need to turn on paging to control the cache. So I guess the no paging is likely more of a i386 issue? > > 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. I'd suggest passing an EFI device path to IS_PECOFF_IMAGE_SUPPORTED. At some point it might be useful for the emulator to know what device is being emulated. For bonus points we could check IsPecoffImageSupported() prior to the native check. Never say never, some one may want to have emulator run on native images for debugging etc. Thanks, Andrew Fish > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel