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

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

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.

Protocols that only allow a single instance need to
clearly document that assumption.

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.

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.

Thanks,

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of Ard Biesheuvel
> Sent: Thursday, September 13, 2018 3:37 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;
> agraf@suse.de; Andrew Fish <afish@apple.com>;
> 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 12 September 2018 at 17:10, Kinney, Michael D
> <michael.d.kinney@intel.com> wrote:
> > Ard,
> >
> > I think there may be a lot of assumptions in this
> > proposal that are not documented.
> >
> > I do not see any description of how an image is
> > started or how calls between native code and emulated
> > code are handled.
> >
> 
> It is the job of the implementation of the emulator to
> use the
> information provided to it at registration time to
> ensure that calls
> to its entry point are handled. One way could be to
> remap the code
> region non-exec (which is what X86EmulatorPkg does) and
> hook the
> exceptions that result when calling into the non-native
> code. Another
> approach could be to do binary translation at load time,
> hook the
> PE/COFF entry point in the header to point to a load
> stub etc etc.
> 
> These are all implementation details of the emulator,
> and so I am not
> sure what exactly we need to document at the protocol
> level. Does the
> above paragraph capture more or less what you mean?
> 
> > Also, are multiple emulated CPUs supported?  It looks
> > like there can only be one instance of this new
> protocol.
> >
> 
> Yes. I am not sure what the added value is of having
> multiple
> emulators. Do you have anything in mind?
> 
> In any case, the singleton protocol could be implemented
> by a wrapper
> driver that encapsulates this multiple dispatch
> functionality. I don't
> think it makes sense to duplicate logic for that purpose
> in the
> various places that I touch in this series, and so it
> shouldn't affect
> the protocol prototypes.
> 
> > Can you please provide more detailed comments for the
> > functions in the new protocol and document the
> assumptions
> > and known limitation in the header?
> >
> 
> Of course. But note that they are fairly simple
> prototypes that don't
> impose any limitations by themselves, other than that
> you should call
> RegisterImage() before attempting to invoke its entry
> point.
> 
> > From one perspective, EBC is an emulated instruction
> set.
> > Would it make sense to have EBC be one of the emulated
> > CPU types that can be plugged in?
> >
> 
> We could definitely abstract away the EBC handling in
> the DXE core to
> be routed via this protocol, but that would make the
> changes more
> intrusive. I could look into making those changes on top
> if there is
> interest.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel