Re: [edk2-devel] [edk2-discuss] Multi-ISA Driver Compatibility Survey

["Laszlo Ersek" <lersek@redhat.com>]

On 1/22/24 20:04, Rebecca Cran wrote:
> Originally posted at
> https://twitter.com/UEFIForum/status/1745518769232077208
> 
> The Multi-ISA Driver Compatibility Survey is at
> https://docs.google.com/forms/d/e/1FAIpQLScXjwaSBgLeqB1coEDxCPxho5JWF3AMqshOTJ2wd6Tf0He4LA/viewform
> 
> From that page:
> 
> Did you know Tiano today supports four 64-bit architectures, yet plug-in
> device OpRoms are still mostly limited to x64 and CSM? While
> binary-translation approaches are a useful stop-gap solution for both
> AArch64 and RV64 ecosystems, we need a common approach that is not a
> technical debt nightmare and that will be adopted by IHVs and endorsed
> by OSVs.
> 
> The  Multi-ISA Driver Compatibility talk went over some of the possible
> approaches, as a lead-in for an open discussion, and raised the
> long-term importance of solving cross-architecture compatibility issues
> for OpRom drivers.
> 
> This survey is an opportunity provide feedback to guide further
> exploration in this space.
> 
> The discussed options were:
> 
> - Do nothing. This is an IHV problem. IHV should continue shipping
> support for whatever architectures they deem necessary.
> - Resurrect EFI Byte Code. Invest in compilers and tooling (e.g.
> addr2line, JIT, etc) to get parity with existing native drivers.
> - Look at WASM, and solve tooling constraints (around sandboxing) that
> prevent adoption.
> - eBPF, and solve tooling constraints (around sandboxing) that prevent
> adoption.
> - Constrained, well-defined subset of x64. This meets IHVs half-way by
> avoiding significant perturbations to existing driver development and
> release processes, and achieves compatibility with existing x64 systems
> in the market "for free", while addressing most of the concerns around
> binary translation of x64 code.

This list seems too restrictive.

As long as IHVs are not interested in their cards booting on non-x86
boards, nothing sustainable can be done.

Assuming IHVs are *slightly* interested (which does not mean "full
support" at all), things can be done. Among those things, binary-based
approaches are all futile, IMO, because they do not allow for debugging
and improvements by the *board* vendor. EBC, WASM, eBFP, constrained X64
are all the same in this regard. If the original driver doesn't perform
proper mapping for DMA for example, that issue can only be identified
and fixed by *source-level* work.

IMO the only sustainable approach is if an IHV licenses the source code
of their driver (containing X64 shortcuts) to the vendor of the
(non-x86) board, preferably including documentation. Then the board
vendor can identify issues, and propose source-level fixes. That's less
burden on the IHV (mostly just regression testing on x86) than taking on
full support themselves. Regarding distribution, the non-x86 binaries
could be distributed on USB sticks (and loaded via Driver####), possibly
even by the board vendor. Not super comfortable for the end-user, but it
would not intrude on the card flash (so the IHV wouldn't have to account
for it).

Of course this requires the IHV to be willing to show their source code
to the board vendor (possibly under NDA). Until that happens, this mess
will persist. In my opinion.

Either way, I believe that this option is not represented in the survey.

Laszlo

> 
> Note: the last three options (WASM, eBPF and constrained x64) are not
> neutral with respect to host natural register width, which will mean a
> break in compatibility with future TBD 128-bit environments, unless a
> TBD OpRom sandboxing technology is invented.
> 
> Note 2: emails and names/sign-ins are not collected, this is an
> anonymous response.
> 
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114203): https://edk2.groups.io/g/devel/message/114203
Mute This Topic: https://groups.io/mt/103910445/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-