From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 5EBB39414CA for ; Tue, 23 Jan 2024 14:44:47 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=abqzmXhzr0GPfFk5+A7+2iprJpmcl+YRhCSdF/BPfqQ=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1706021086; v=1; b=HrhQJmcTfXSxJt4MIagLdtXyOYubJDFUWTvKEB1XV59VFJPUYXAQX8FK0omIbiPTWvyKhrCY 8b/o20JoKP2CTTGCWOP8ktM4kGCjfQ+EbPFgxMTiZHFTaj6qTEGZ+juHq4WxjsQwsuLN4mim4s8 I4lHgtjx7ypFn0y/zA9kzDu0= X-Received: by 127.0.0.2 with SMTP id R50WYY7687511xzzbp7208uf; Tue, 23 Jan 2024 06:44:46 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.13984.1706021085454369590 for ; Tue, 23 Jan 2024 06:44:45 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-322-If4LaplwNJqUPJ7U1lTEnQ-1; Tue, 23 Jan 2024 09:44:43 -0500 X-MC-Unique: If4LaplwNJqUPJ7U1lTEnQ-1 X-Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E02623816B40; Tue, 23 Jan 2024 14:44:42 +0000 (UTC) X-Received: from [10.39.194.212] (unknown [10.39.194.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3D78B2166B32; Tue, 23 Jan 2024 14:44:42 +0000 (UTC) Message-ID: Date: Tue, 23 Jan 2024 15:44:41 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [edk2-discuss] Multi-ISA Driver Compatibility Survey To: discuss@edk2.groups.io, rebecca@bsdio.com, "devel@edk2.groups.io" Cc: "rfc@edk2.groups.io" References: <53d076f2-50a5-47d1-8df7-c0e3dace99ee@bsdio.com> From: "Laszlo Ersek" In-Reply-To: <53d076f2-50a5-47d1-8df7-c0e3dace99ee@bsdio.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: fWRlFa5v8urXZEuG9RvGuL1ix7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=HrhQJmcT; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io 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] -=-=-=-=-=-=-=-=-=-=-=-