Re: [PATCH 0/4] MdeModulePkg: add support for dispatching foreign arch PE/COFF images

["Kinney, Michael D" <michael.d.kinney@intel.com>]

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 <michael.d.kinney@intel.com>
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Zimmer, Vincent
> <vincent.zimmer@intel.com>; Dong, Eric
> <eric.dong@intel.com>; edk2-devel@lists.01.org; Andrew
> Fish <afish@apple.com>; agraf@suse.de; Richardson, Brian
> <brian.richardson@intel.com>; Laszlo Ersek
> <lersek@redhat.com>; Zeng, Star <star.zeng@intel.com>
> Subject: Re: [edk2] [PATCH 0/4] MdeModulePkg: add support
> for dispatching foreign arch PE/COFF images
> 
> On 13 September 2018 at 19:20, Kinney, Michael D
> <michael.d.kinney@intel.com> 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.
> 
> > 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?
> 
> 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