From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.67; helo=nwk-aaemail-lapp02.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 53E31211350F1 for ; Fri, 21 Sep 2018 11:51:48 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w8LIphoi049202; Fri, 21 Sep 2018 11:51:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=9xCqSCwTcwpFKPEVRJLhutmftdP/RkMPuwoaHxAYzsg=; b=Jpw1ntU91tBjtidHs8ygcI5bkvTKwM9YKCuRytROlgvtGcSA5RPbXzc7hFyr8Nwj0dPP cEl5KasGTmlhUU6y/V3nmeIrlDOZ9sdP7L40j6ufij4T4u/nojtKKwc+IkUth4mJx0P0 18hLkD5RQgh0KdmObkPpOXUxbgqz9f2vVmo4T1tlsOiHANyv2ADObCerqBJZC0bv9eey HtoRHI2+NO3+NbneMR08ZlhofZ6tG40Bld1kGOV3hStnLpZorTaw2gmLBVYbeDDiRNqd AaRyqXkNXw+v+tX88nILJtm0Boa8VO3ztFFn9/Q7yzDibhEovc1YzSC1D8J55Sfyia7+ mA== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2mmkmda85d-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 21 Sep 2018 11:51:47 -0700 MIME-version: 1.0 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PFF00ISI5Q89380@mr2-mtap-s01.rno.apple.com>; Fri, 21 Sep 2018 11:51:45 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFF00E005BCTT00@ma1-mmpp-sz09.apple.com>; Fri, 21 Sep 2018 11:51:44 -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: 07e9ae2d-d782-4c8b-9bad-1dca2eb20fc7 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: 14debcba-c6a2-4c9f-ad5f-7905b7eeb277 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFF00I005O2F400@ma1-mmpp-sz09.apple.com>; Fri, 21 Sep 2018 11:51:43 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-21_07:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp22.corp.apple.com-10000_instance1 Received: from [17.234.198.76] (unknown [17.234.198.76]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PFF00GGM5Q47Y00@ma1-mmpp-sz09.apple.com>; Fri, 21 Sep 2018 11:51:43 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: Date: Fri, 21 Sep 2018 11:51:23 -0700 In-reply-to: Cc: Mike Kinney , "Ni, Ruiyu" , Vincent Zimmer , "Dong, Eric" , "edk2-devel@lists.01.org" , "agraf@suse.de" , "Richardson, Brian" , Laszlo Ersek , "Zeng, Star" To: Ard Biesheuvel References: <20180912132151.4258-1-ard.biesheuvel@linaro.org> <158F7824-8679-4121-9E7D-5C3593808909@apple.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-21_07:, , signatures=0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Fri, 21 Sep 2018 18:51:48 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On Sep 19, 2018, at 1:43 PM, Ard Biesheuvel wrote: > > On 19 September 2018 at 12:35, Andrew Fish > wrote: >> >> >>> 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. >> > > Oh, I'm sure - but my point is that whether architecture X can be > emulated on architecture Y and how is a limitation that affects some > implementations of the protocol, but at the abstract level that we > deal with in the core code, it is not a concern. > >>>> 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? >> > > Michael spotted yesterday that RISC-V mandates paging disabled, which > is peculiar in itself. But again, whether a certain implementation of > the protocol relies on paging or not is an implementation detail. > >>> >>> 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. >> > > I guess you mean for which device we are loading a driver that relies > on emulation? I guess that makes sense for option ROMs, which is the > primary use case, so yes, I can add that. > >> 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. >> > > Peter brought this up as well - in some cases, you may want to sandbox > X86 drivers running on X86 by running them on an emulator. If you > think the overhead of performing this check for each image rather than > only for images that have already been found to be for a foreign > architecture is acceptables then I'm happy to change this. But we can > easily do that later as well. Ard, I vote for the flexibility. Given ImageType is passed into IsImageSupported() in the simple case it is just going to be checking a register (argument) against a constant. Thanks, Andrew Fish '