mbox series

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

Message ID 20180912132151.4258-1-ard.biesheuvel@linaro.org
Headers show
Series MdeModulePkg: add support for dispatching foreign arch PE/COFF images | expand

Message

Ard Biesheuvel Sept. 12, 2018, 1:21 p.m. UTC 
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 an emulator.

One implementation of such an emulator can be found here:
https://github.com/ardbiesheuvel/X86EmulatorPkg

Cc: Zimmer Vincent <vincent.zimmer@intel.com>
Cc: Brian Richardson <brian.richardson@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>

Ard Biesheuvel (4):
  MdeModulePkg: introduce PE/COFF image emulator protocol
  MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images
  MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for foreign option
    ROMs
  MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +
 .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16 +++++-
 MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++
 MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +
 MdeModulePkg/Core/Dxe/Image/Image.c           | 39 +++++++++++---
 .../Include/Protocol/PeCoffImageEmulator.h    | 51 +++++++++++++++++++
 .../Library/UefiBootManagerLib/BmLoadOption.c | 26 +++++++++-
 .../Library/UefiBootManagerLib/InternalBm.h   |  1 +
 .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +
 MdeModulePkg/MdeModulePkg.dec                 |  4 ++
 11 files changed, 136 insertions(+), 8 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

-- 
2.17.1

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Comments

Gao, Liming Sept. 12, 2018, 2:55 p.m. UTC | #1 
Ard:
  What's purpose to run the not native image in emulator? And, what should be done in the emulator driver, such as X64Emulator? Is the emulator responsible to translate the instruction between the different arch? I see X64Emualtor bases on qemu code. 

Thanks
Liming
> -----Original Message-----

> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel

> Sent: Wednesday, September 12, 2018 9:22 PM

> To: edk2-devel@lists.01.org

> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Zimmer, Vincent <vincent.zimmer@intel.com>; Dong, Eric <eric.dong@intel.com>; Andrew Fish

> <afish@apple.com>; agraf@suse.de; Richardson, Brian <brian.richardson@intel.com>; Kinney, Michael D

> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; Zeng, Star <star.zeng@intel.com>

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

> 

> 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 an emulator.

> 

> One implementation of such an emulator can be found here:

> https://github.com/ardbiesheuvel/X86EmulatorPkg

> 

> Cc: Zimmer Vincent <vincent.zimmer@intel.com>

> Cc: Brian Richardson <brian.richardson@intel.com>

> Cc: Michael D Kinney <michael.d.kinney@intel.com>

> Cc: Andrew Fish <afish@apple.com>

> Cc: Laszlo Ersek <lersek@redhat.com>

> Cc: Leif Lindholm <leif.lindholm@linaro.org>

> Cc: Star Zeng <star.zeng@intel.com>

> Cc: Eric Dong <eric.dong@intel.com>

> Cc: Ruiyu Ni <ruiyu.ni@intel.com>

> 

> Ard Biesheuvel (4):

>   MdeModulePkg: introduce PE/COFF image emulator protocol

>   MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images

>   MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for foreign option

>     ROMs

>   MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

> 

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +

>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16 +++++-

>  MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++

>  MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +

>  MdeModulePkg/Core/Dxe/Image/Image.c           | 39 +++++++++++---

>  .../Include/Protocol/PeCoffImageEmulator.h    | 51 +++++++++++++++++++

>  .../Library/UefiBootManagerLib/BmLoadOption.c | 26 +++++++++-

>  .../Library/UefiBootManagerLib/InternalBm.h   |  1 +

>  .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +

>  MdeModulePkg/MdeModulePkg.dec                 |  4 ++

>  11 files changed, 136 insertions(+), 8 deletions(-)

>  create mode 100644 MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

> 

> --

> 2.17.1

> 

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Sept. 12, 2018, 2:56 p.m. UTC | #2 
On 12 September 2018 at 16:55, Gao, Liming <liming.gao@intel.com> wrote:
> Ard:

>   What's purpose to run the not native image in emulator? And, what should be done in the emulator driver, such as X64Emulator? Is the emulator responsible to translate the instruction between the different arch? I see X64Emualtor bases on qemu code.

>


The primary use case is option ROMs on PCIe cards.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Carsey, Jaben Sept. 12, 2018, 3:07 p.m. UTC | #3 
Ard,

What happens when more than one emulators want to co-exist?

-Jaben

> -----Original Message-----

> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of

> Ard Biesheuvel

> Sent: Wednesday, September 12, 2018 7:57 AM

> To: Gao, Liming <liming.gao@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>; Kinney, Michael D

> <michael.d.kinney@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 16:55, Gao, Liming <liming.gao@intel.com> wrote:

> > Ard:

> >   What's purpose to run the not native image in emulator? And, what

> should be done in the emulator driver, such as X64Emulator? Is the emulator

> responsible to translate the instruction between the different arch? I see

> X64Emualtor bases on qemu code.

> >

> 

> The primary use case is option ROMs on PCIe cards.

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Kinney, Michael D Sept. 12, 2018, 3:10 p.m. UTC | #4 
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.

Also, are multiple emulated CPUs supported?  It looks
like there can only be one instance of this new protocol.

Can you please provide more detailed comments for the
functions in the new protocol and document the assumptions
and known limitation in the header?

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?

Thanks,

Mike

> -----Original Message-----

> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]

> Sent: Wednesday, September 12, 2018 6:22 AM

> To: edk2-devel@lists.01.org

> Cc: agraf@suse.de; Ard Biesheuvel

> <ard.biesheuvel@linaro.org>; 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>; Laszlo Ersek <lersek@redhat.com>;

> Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star

> <star.zeng@intel.com>; Dong, Eric <eric.dong@intel.com>;

> Ni, Ruiyu <ruiyu.ni@intel.com>

> Subject: [PATCH 0/4] MdeModulePkg: add support for

> dispatching foreign arch PE/COFF images

> 

> 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

> an emulator.

> 

> One implementation of such an emulator can be found

> here:

> https://github.com/ardbiesheuvel/X86EmulatorPkg

> 

> Cc: Zimmer Vincent <vincent.zimmer@intel.com>

> Cc: Brian Richardson <brian.richardson@intel.com>

> Cc: Michael D Kinney <michael.d.kinney@intel.com>

> Cc: Andrew Fish <afish@apple.com>

> Cc: Laszlo Ersek <lersek@redhat.com>

> Cc: Leif Lindholm <leif.lindholm@linaro.org>

> Cc: Star Zeng <star.zeng@intel.com>

> Cc: Eric Dong <eric.dong@intel.com>

> Cc: Ruiyu Ni <ruiyu.ni@intel.com>

> 

> Ard Biesheuvel (4):

>   MdeModulePkg: introduce PE/COFF image emulator

> protocol

>   MdeModulePkg/DxeCore: invoke the emulator protocol for

> foreign images

>   MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for

> foreign option

>     ROMs

>   MdeModulePkg/UefiBootManagerLib: allow foreign

> Driver#### images

> 

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +

>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16

> +++++-

>  MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++

>  MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +

>  MdeModulePkg/Core/Dxe/Image/Image.c           | 39

> +++++++++++---

>  .../Include/Protocol/PeCoffImageEmulator.h    | 51

> +++++++++++++++++++

>  .../Library/UefiBootManagerLib/BmLoadOption.c | 26

> +++++++++-

>  .../Library/UefiBootManagerLib/InternalBm.h   |  1 +

>  .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +

>  MdeModulePkg/MdeModulePkg.dec                 |  4 ++

>  11 files changed, 136 insertions(+), 8 deletions(-)

>  create mode 100644

> MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

> 

> --

> 2.17.1


_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Sept. 12, 2018, 3:11 p.m. UTC | #5 
On 12 September 2018 at 17:07, Carsey, Jaben <jaben.carsey@intel.com> wrote:
> Ard,

>

> What happens when more than one emulators want to co-exist?

>


The protocol does not support that at the moment, and it is doubtful
that it would work in practice: the X86-on-AARCH64 emulator works by
mapping the X86 PE/COFF code regions as non-executable, and trapping
the resulting exception to invoke the emulator. Running multiple
emulators side by side would require a considerable amount of
synchronization, so it only makes sense to consider that if there is a
compelling use case. And if there is, we could still abstract from
this at the top level (i.e., this protocol)
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Carsey, Jaben Sept. 12, 2018, 3:48 p.m. UTC | #6 
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>


Code looks good to me.


> -----Original Message-----

> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of

> Ard Biesheuvel

> Sent: Wednesday, September 12, 2018 6:22 AM

> To: edk2-devel@lists.01.org

> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Zimmer, Vincent

> <vincent.zimmer@intel.com>; Dong, Eric <eric.dong@intel.com>; Andrew

> Fish <afish@apple.com>; agraf@suse.de; Richardson, Brian

> <brian.richardson@intel.com>; Kinney, Michael D

> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; Zeng,

> Star <star.zeng@intel.com>

> Subject: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching

> foreign arch PE/COFF images

> 

> 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 an emulator.

> 

> One implementation of such an emulator can be found here:

> https://github.com/ardbiesheuvel/X86EmulatorPkg

> 

> Cc: Zimmer Vincent <vincent.zimmer@intel.com>

> Cc: Brian Richardson <brian.richardson@intel.com>

> Cc: Michael D Kinney <michael.d.kinney@intel.com>

> Cc: Andrew Fish <afish@apple.com>

> Cc: Laszlo Ersek <lersek@redhat.com>

> Cc: Leif Lindholm <leif.lindholm@linaro.org>

> Cc: Star Zeng <star.zeng@intel.com>

> Cc: Eric Dong <eric.dong@intel.com>

> Cc: Ruiyu Ni <ruiyu.ni@intel.com>

> 

> Ard Biesheuvel (4):

>   MdeModulePkg: introduce PE/COFF image emulator protocol

>   MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images

>   MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for foreign option

>     ROMs

>   MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

> 

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +

>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16 +++++-

>  MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++

>  MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +

>  MdeModulePkg/Core/Dxe/Image/Image.c           | 39 +++++++++++---

>  .../Include/Protocol/PeCoffImageEmulator.h    | 51 +++++++++++++++++++

>  .../Library/UefiBootManagerLib/BmLoadOption.c | 26 +++++++++-

>  .../Library/UefiBootManagerLib/InternalBm.h   |  1 +

>  .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +

>  MdeModulePkg/MdeModulePkg.dec                 |  4 ++

>  11 files changed, 136 insertions(+), 8 deletions(-)

>  create mode 100644

> MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

> 

> --

> 2.17.1

> 

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Zimmer, Vincent Sept. 12, 2018, 6:50 p.m. UTC | #7 
I like this approach too

Vincent

> On Sep 12, 2018, at 5:48 PM, Carsey, Jaben <jaben.carsey@intel.com> wrote:

> 

> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>

> 

> Code looks good to me.

> 

> 

>> -----Original Message-----

>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of

>> Ard Biesheuvel

>> Sent: Wednesday, September 12, 2018 6:22 AM

>> To: edk2-devel@lists.01.org

>> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Zimmer, Vincent

>> <vincent.zimmer@intel.com>; Dong, Eric <eric.dong@intel.com>; Andrew

>> Fish <afish@apple.com>; agraf@suse.de; Richardson, Brian

>> <brian.richardson@intel.com>; Kinney, Michael D

>> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; Zeng,

>> Star <star.zeng@intel.com>

>> Subject: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching

>> foreign arch PE/COFF images

>> 

>> 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 an emulator.

>> 

>> One implementation of such an emulator can be found here:

>> https://github.com/ardbiesheuvel/X86EmulatorPkg

>> 

>> Cc: Zimmer Vincent <vincent.zimmer@intel.com>

>> Cc: Brian Richardson <brian.richardson@intel.com>

>> Cc: Michael D Kinney <michael.d.kinney@intel.com>

>> Cc: Andrew Fish <afish@apple.com>

>> Cc: Laszlo Ersek <lersek@redhat.com>

>> Cc: Leif Lindholm <leif.lindholm@linaro.org>

>> Cc: Star Zeng <star.zeng@intel.com>

>> Cc: Eric Dong <eric.dong@intel.com>

>> Cc: Ruiyu Ni <ruiyu.ni@intel.com>

>> 

>> Ard Biesheuvel (4):

>>  MdeModulePkg: introduce PE/COFF image emulator protocol

>>  MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images

>>  MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for foreign option

>>    ROMs

>>  MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

>> 

>> MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +

>> MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +

>> .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16 +++++-

>> MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++

>> MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +

>> MdeModulePkg/Core/Dxe/Image/Image.c           | 39 +++++++++++---

>> .../Include/Protocol/PeCoffImageEmulator.h    | 51 +++++++++++++++++++

>> .../Library/UefiBootManagerLib/BmLoadOption.c | 26 +++++++++-

>> .../Library/UefiBootManagerLib/InternalBm.h   |  1 +

>> .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +

>> MdeModulePkg/MdeModulePkg.dec                 |  4 ++

>> 11 files changed, 136 insertions(+), 8 deletions(-)

>> create mode 100644

>> MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

>> 

>> --

>> 2.17.1

>> 

>> _______________________________________________

>> edk2-devel mailing list

>> edk2-devel@lists.01.org

>> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Shi, Steven Sept. 13, 2018, 12:47 a.m. UTC | #8 
Hi Ard,
Just my curious, are you supporting the below idea of QEMU in UEFI?

QEMU in UEFI - Alexander Graf
https://www.youtube.com/watch?v=uxvAH1Q4Mx0
http://events17.linuxfoundation.org/sites/events/files/slides/QEMU%20in%20UEFI.pdf



Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

> -----Original Message-----

> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of

> Ard Biesheuvel

> Sent: Wednesday, September 12, 2018 9:22 PM

> To: edk2-devel@lists.01.org

> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Zimmer, Vincent

> <vincent.zimmer@intel.com>; Dong, Eric <eric.dong@intel.com>; Andrew

> Fish <afish@apple.com>; agraf@suse.de; Richardson, Brian

> <brian.richardson@intel.com>; Kinney, Michael D

> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; Zeng,

> Star <star.zeng@intel.com>

> Subject: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching

> foreign arch PE/COFF images

> 

> 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 an emulator.

> 

> One implementation of such an emulator can be found here:

> https://github.com/ardbiesheuvel/X86EmulatorPkg

> 

> Cc: Zimmer Vincent <vincent.zimmer@intel.com>

> Cc: Brian Richardson <brian.richardson@intel.com>

> Cc: Michael D Kinney <michael.d.kinney@intel.com>

> Cc: Andrew Fish <afish@apple.com>

> Cc: Laszlo Ersek <lersek@redhat.com>

> Cc: Leif Lindholm <leif.lindholm@linaro.org>

> Cc: Star Zeng <star.zeng@intel.com>

> Cc: Eric Dong <eric.dong@intel.com>

> Cc: Ruiyu Ni <ruiyu.ni@intel.com>

> 

> Ard Biesheuvel (4):

>   MdeModulePkg: introduce PE/COFF image emulator protocol

>   MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images

>   MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for foreign option

>     ROMs

>   MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

> 

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +

>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +

>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16 +++++-

>  MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++

>  MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +

>  MdeModulePkg/Core/Dxe/Image/Image.c           | 39 +++++++++++---

>  .../Include/Protocol/PeCoffImageEmulator.h    | 51 +++++++++++++++++++

>  .../Library/UefiBootManagerLib/BmLoadOption.c | 26 +++++++++-

>  .../Library/UefiBootManagerLib/InternalBm.h   |  1 +

>  .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +

>  MdeModulePkg/MdeModulePkg.dec                 |  4 ++

>  11 files changed, 136 insertions(+), 8 deletions(-)

>  create mode 100644

> MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

> 

> --

> 2.17.1

> 

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Sept. 13, 2018, 5:18 a.m. UTC | #9 
On 13 September 2018 at 02:47, Shi, Steven <steven.shi@intel.com> wrote:
> Hi Ard,

> Just my curious, are you supporting the below idea of QEMU in UEFI?

>

> QEMU in UEFI - Alexander Graf

> https://www.youtube.com/watch?v=uxvAH1Q4Mx0

> http://events17.linuxfoundation.org/sites/events/files/slides/QEMU%20in%20UEFI.pdf

>


Yes. X86EmulatorPkg was developed by Alexander and myself.


>> -----Original Message-----

>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of

>> Ard Biesheuvel

>> Sent: Wednesday, September 12, 2018 9:22 PM

>> To: edk2-devel@lists.01.org

>> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Zimmer, Vincent

>> <vincent.zimmer@intel.com>; Dong, Eric <eric.dong@intel.com>; Andrew

>> Fish <afish@apple.com>; agraf@suse.de; Richardson, Brian

>> <brian.richardson@intel.com>; Kinney, Michael D

>> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; Zeng,

>> Star <star.zeng@intel.com>

>> Subject: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching

>> foreign arch PE/COFF images

>>

>> 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 an emulator.

>>

>> One implementation of such an emulator can be found here:

>> https://github.com/ardbiesheuvel/X86EmulatorPkg

>>

>> Cc: Zimmer Vincent <vincent.zimmer@intel.com>

>> Cc: Brian Richardson <brian.richardson@intel.com>

>> Cc: Michael D Kinney <michael.d.kinney@intel.com>

>> Cc: Andrew Fish <afish@apple.com>

>> Cc: Laszlo Ersek <lersek@redhat.com>

>> Cc: Leif Lindholm <leif.lindholm@linaro.org>

>> Cc: Star Zeng <star.zeng@intel.com>

>> Cc: Eric Dong <eric.dong@intel.com>

>> Cc: Ruiyu Ni <ruiyu.ni@intel.com>

>>

>> Ard Biesheuvel (4):

>>   MdeModulePkg: introduce PE/COFF image emulator protocol

>>   MdeModulePkg/DxeCore: invoke the emulator protocol for foreign images

>>   MdeModulePkg/PciBusDxe: invoke PE/COFF emulator for foreign option

>>     ROMs

>>   MdeModulePkg/UefiBootManagerLib: allow foreign Driver#### images

>>

>>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h       |  1 +

>>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf  |  1 +

>>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   | 16 +++++-

>>  MdeModulePkg/Core/Dxe/DxeMain.h               |  3 ++

>>  MdeModulePkg/Core/Dxe/DxeMain.inf             |  1 +

>>  MdeModulePkg/Core/Dxe/Image/Image.c           | 39 +++++++++++---

>>  .../Include/Protocol/PeCoffImageEmulator.h    | 51 +++++++++++++++++++

>>  .../Library/UefiBootManagerLib/BmLoadOption.c | 26 +++++++++-

>>  .../Library/UefiBootManagerLib/InternalBm.h   |  1 +

>>  .../UefiBootManagerLib/UefiBootManagerLib.inf |  1 +

>>  MdeModulePkg/MdeModulePkg.dec                 |  4 ++

>>  11 files changed, 136 insertions(+), 8 deletions(-)

>>  create mode 100644

>> MdeModulePkg/Include/Protocol/PeCoffImageEmulator.h

>>

>> --

>> 2.17.1

>>

>> _______________________________________________

>> edk2-devel mailing list

>> edk2-devel@lists.01.org

>> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Sept. 13, 2018, 10:36 a.m. UTC | #10 
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
Kinney, Michael D Sept. 13, 2018, 5:20 p.m. UTC | #11 
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

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Sept. 15, 2018, 1:28 p.m. UTC | #12 
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
Kinney, Michael D Sept. 17, 2018, 4:03 a.m. UTC | #13 
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

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Andrew Fish Sept. 19, 2018, 7:35 p.m. UTC | #14 
> On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> 

> 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.

> 


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. 

>> 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? 

> 

> 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. 

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. 

Thanks,

Andrew Fish

> _______________________________________________

> edk2-devel mailing list

> edk2-devel@lists.01.org

> https://lists.01.org/mailman/listinfo/edk2-devel


_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Ard Biesheuvel Sept. 19, 2018, 8:43 p.m. UTC | #15 
On 19 September 2018 at 12:35, Andrew Fish <afish@apple.com> wrote:
>

>

>> On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>

>> 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.

>>

>

> 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.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Andrew Fish Sept. 21, 2018, 6:51 p.m. UTC | #16 
> On Sep 19, 2018, at 1:43 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> 

> On 19 September 2018 at 12:35, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:

>> 

>> 

>>> On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>> 

>>> 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.

>>> 

>> 

>> 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

'

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel