From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=FqJSLA4U; spf=pass (domain: linaro.org, ip: 209.85.166.67, mailfrom: ard.biesheuvel@linaro.org) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by groups.io with SMTP; Thu, 11 Apr 2019 13:57:46 -0700 Received: by mail-io1-f67.google.com with SMTP id u12so6577756iop.11 for ; Thu, 11 Apr 2019 13:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVVCcMeJlW48ZQFpr30YzEBTNhHuHzdxgjCGbAUWS+E=; b=FqJSLA4UDmslcsajAfLP6rgYpMY9lsFjwcrsytC2gU23Upy0wk2OQ2IlD/ee9vmr2X 0Tr60UF+KgNsY8qFzZr9JBmV0c6Mcj1NpktVsbA3MO70fMTMMr7vVlHh863ozgPLWiQJ 5P6fr+V+E9FsHqyERmRAUhunRm4w6ELwkaXPjf5jl5SZlEFYnb4mnL6zaj9suGvLXmOQ hG7Q65ZeLoROYug4O/vK50/7V6iIjQbtbYOoLVboupalmFPaqtdHFNpcV7FWFiw6Bzgv zWOLqLC87zzucOecYHADxw7u2KugsXT88U/ePLfsepxbElFVFZIfdDC4nW7cg0KlpDcY yd2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVVCcMeJlW48ZQFpr30YzEBTNhHuHzdxgjCGbAUWS+E=; b=Pcnd/US1ZO74K/tw31xelpoyziC6ItjDPeyINUwg8ecpp9X/Hw2PT1g+m1/BVLAx3H BU8hKnsqqQXbxiL1L7wwhRujB4WxyjuTz4izQ9rxOEoMUpYO6dHsxW65oDq7Ey0wHMAZ ylW8qMRv+tivlUAdIpvh1gkt4nc7bjrj5s2Q816EU8UctcflihDzXqu4Qcovlcme1sOS AKHAgKUqFM5hz7+29w28KiNWa1YWjcoKQGMZeYGZtG6e6KyIaVXaX3TCLxLSFUIoTP7D rzYv4Ku3UBFVGhFJr3mpBK1lIgI7wGcIMHPEcobNcKIPmLKGM4FaIGrZccIvQKjkj9x4 QObQ== X-Gm-Message-State: APjAAAVktuIRNUmgvy1/wGceium8uWq6f9D5K0VrqQuTUcPb9grWSiZr JQnAhnX/xqQIt+sfy8opwGD60gF28NcKTgCtN91JgDPmS3lh4RXs X-Google-Smtp-Source: APXvYqzZApPKF/CYdaIdBcjPeSmiIUWk+FkFuQcEOKHSPq7j0hAxx4ucFTBQp7TZfU2YL/4+4IsAFKlWu3wXx2YPTxk= X-Received: by 2002:a6b:3b07:: with SMTP id i7mr8146151ioa.230.1555016265391; Thu, 11 Apr 2019 13:57:45 -0700 (PDT) MIME-Version: 1.0 References: <1594808A1A875F21.10226@groups.io> In-Reply-To: <1594808A1A875F21.10226@groups.io> From: "Ard Biesheuvel" Date: Thu, 11 Apr 2019 13:57:34 -0700 Message-ID: Subject: Re: [edk2-devel] [PATCH v5 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images To: edk2-devel-groups-io , Ard Biesheuvel Cc: Vincent Zimmer , Brian Richardson , Michael D Kinney , Andrew Fish , Leif Lindholm , Star Zeng , Eric Dong , Ruiyu Ni , Liming Gao , Jaben Carsey , Steven Shi Content-Type: text/plain; charset="UTF-8" On Thu, 11 Apr 2019 at 11:58, Ard Biesheuvel via Groups.Io wrote: > > Add the basic plumbing to DXE core, the PCI bus driver and the boot manager > to allow PE/COFF images to be dispatched that target an architecture that is > not native for the platform, but which is supported by one of potentially > several available emulators. > > One implementation of such an emulator can be found here: > https://github.com/ardbiesheuvel/X86EmulatorPkg/tree/upstream-v4 > > This also allows us to get rid of the special treatment of EBC images in > core code. Instead, the EbcDxe driver is augmented with an implementation > of the EDK2 PE/COFF image emulator protocol so that internal knowledge of > how EBC is implemented (I-cache flushing, thunks) is removed from the DXE > core. > > Changes since v4: > - Fix an issue in the protocol notify handler pointed out by Mike Kinney (#2) > > Changes since v3: > - Simplify the handling of option ROMs and Driver#### images, by simply > deferring to the LoadImage() boot service to decide whether an image > can be supported or not - this removes some redundant checks from the > BDS layer and the PCI bus driver. > - Move the machine type supported by the emulator into the protocol struct, > so we can optimize away calls into the emulator for each image loaded. > Instead, the LoadImage() code will only invoke the IsSupported() method for > images that are known to have a matching machine type. > > Note that I have considered, but ultimately dismissed the suggestion to > register and unregister emulators via a new protocol. The main issue is > that registering and unregistering structs containing sets of function > pointers is awfully similar to managing a protocol database, and we already > have the code to do that in EDK2. > > So instead, I have removed all the code that iterates over a handle buffer > of emu protocols and invokes each one to see if it will support the image. > Instead, this is all done by CoreLoadImage(). > > Changes since v2: > - incorporate feedback from Andrew Fish (delivered in person): > * pass a device path into the IsImageSupported() protocol method so that an > implementation can blacklist or whitelist certain devices, or implement > other policies that depend on the device where the driver originated > * allow the emulator to supersede the native loading of the image - this > permits things like X86 on X86 emulators for security sandboxing or debug > > Changes since v1: > - subsume the EBC handling into the EDK2 emulator protocol and abstract > away from EBC specifics in core code. > - allow multiple emulator implementations to co-exist > - incorporate Star's review feedback > In order not to spam everyone with another revision within a couple of hours, I have applied the feedback from Mike for the VS build errors and pushed the result here: https://github.com/ardbiesheuvel/edk2/pull/new/pecoff-emu-v5+ in case the MdeModulePkg maintainers want to pull the code and test it during review.