* Re: [edk2-devel] [PATCH v5 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images
[not found] <1594808A1A875F21.10226@groups.io>
@ 2019-04-11 20:57 ` Ard Biesheuvel
2019-04-12 20:58 ` Michael D Kinney
0 siblings, 1 reply; 3+ messages in thread
From: Ard Biesheuvel @ 2019-04-11 20:57 UTC (permalink / raw)
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
On Thu, 11 Apr 2019 at 11:58, Ard Biesheuvel via Groups.Io
<ard.biesheuvel=linaro.org@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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [edk2-devel] [PATCH v5 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images
2019-04-11 20:57 ` [edk2-devel] [PATCH v5 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images Ard Biesheuvel
@ 2019-04-12 20:58 ` Michael D Kinney
2019-04-12 21:03 ` Ard Biesheuvel
0 siblings, 1 reply; 3+ messages in thread
From: Michael D Kinney @ 2019-04-12 20:58 UTC (permalink / raw)
To: Ard Biesheuvel, edk2-devel-groups-io, Kinney, Michael D
Cc: Zimmer, Vincent, Richardson, Brian, Andrew Fish, Leif Lindholm,
Zeng, Star, Dong, Eric, Ni, Ray, Gao, Liming, Carsey, Jaben,
Shi, Steven
Ard,
We have verified that the build failures are resolved.
Series Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Mike
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Thursday, April 11, 2019 1:58 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Zimmer, Vincent <vincent.zimmer@intel.com>;
> Richardson, Brian <brian.richardson@intel.com>; Kinney,
> Michael D <michael.d.kinney@intel.com>; Andrew Fish
> <afish@apple.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Zeng, Star
> <star.zeng@intel.com>; Dong, Eric
> <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Gao,
> Liming <liming.gao@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>; Shi, Steven
> <steven.shi@intel.com>
> Subject: Re: [edk2-devel] [PATCH v5 0/7] MdeModulePkg:
> add support for dispatching foreign arch PE/COFF images
>
> On Thu, 11 Apr 2019 at 11:58, Ard Biesheuvel via
> Groups.Io
> <ard.biesheuvel=linaro.org@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/up
> stream-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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [edk2-devel] [PATCH v5 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images
2019-04-12 20:58 ` Michael D Kinney
@ 2019-04-12 21:03 ` Ard Biesheuvel
0 siblings, 0 replies; 3+ messages in thread
From: Ard Biesheuvel @ 2019-04-12 21:03 UTC (permalink / raw)
To: Kinney, Michael D
Cc: edk2-devel-groups-io, Zimmer, Vincent, Richardson, Brian,
Andrew Fish, Leif Lindholm, Zeng, Star, Dong, Eric, Ni, Ray,
Gao, Liming, Carsey, Jaben, Shi, Steven
On Fri, 12 Apr 2019 at 13:58, Kinney, Michael D
<michael.d.kinney@intel.com> wrote:
>
> Ard,
>
> We have verified that the build failures are resolved.
>
> Series Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
>
Mike,
Thanks a lot for the effort in testing and reviewing.
I'll wait for the MdeModulePkg maintainers' feedback before spinning a
final version and pushing it.
Thanks,
Ard.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-04-12 21:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1594808A1A875F21.10226@groups.io>
2019-04-11 20:57 ` [edk2-devel] [PATCH v5 0/7] MdeModulePkg: add support for dispatching foreign arch PE/COFF images Ard Biesheuvel
2019-04-12 20:58 ` Michael D Kinney
2019-04-12 21:03 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox