From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.91.1604328591019749082 for ; Mon, 02 Nov 2020 06:49:51 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Hx7nEIbY; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604328590; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6hf97jazcT5gy+XDgZoKSUeFl7KZc14sa8OYEZe9aqI=; b=Hx7nEIbYSP69usDeO2bICYn/xy2iqnIQT5GMe8r8CpaERblGuSxsTbcEuavpmAPa3RqvrF EK2qzrirna8X4kNf9vaYsB/UcDPDBiotZvSWtL/8YIHTncB6246qHIdqMPtQnvrbZ6y8yN mZpQy7z2D/AVbmY0eaTKVFIHe1AyM64= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-301-0hcdTOUDN3eE3PLYGh9qPQ-1; Mon, 02 Nov 2020 09:49:48 -0500 X-MC-Unique: 0hcdTOUDN3eE3PLYGh9qPQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 88C026D5A0; Mon, 2 Nov 2020 14:49:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-126.ams2.redhat.com [10.36.112.126]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3F59F6EF50; Mon, 2 Nov 2020 14:49:44 +0000 (UTC) Subject: Re: [edk2-devel] RFC: Universal Payload Interface To: "Ni, Ray" , "devel@edk2.groups.io" Cc: "Zimmer, Vincent" , "Ma, Maurice" , "Rangarajan, Ravi P" , "Dong, Guo" , "Hau, Tze-ming" , "Ard Biesheuvel (ARM address)" , "Leif Lindholm (Nuvia address)" References: From: "Laszlo Ersek" Message-ID: Date: Mon, 2 Nov 2020 15:49:43 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/28/20 04:26, Ni, Ray wrote: > Laszlo, > Thank you for the comments. > Reply inline. > >> -----Original Message----- >> From: devel@edk2.groups.io On Behalf Of Laszlo >> Ersek >> Sent: Tuesday, October 27, 2020 10:21 PM >> To: devel@edk2.groups.io; Ni, Ray >> Cc: Zimmer, Vincent ; Ma, Maurice >> ; Rangarajan, Ravi P ; >> Dong, Guo ; Hau, Tze-ming >> Subject: Re: [edk2-devel] RFC: Universal Payload Interface >> >> On 10/23/20 03:18, Ni, Ray wrote: >>> With the fact that there are many different firmware implementations, we >> tried to decouple today's monolithic UEFI firmware binary to two independent >> components: bootloader and payload. >> >> (1) "Bootloader" is an extremely loaded word. Regardless of everything >> else in this topic, I strongly suggest picking a different name. >> >> We already have "Platform Init" or "PI"; maybe use "Silicon Init" or "SI"? > I am a UEFI guy for many years. So your suggestion "PI" looks very friendly to me. > But I am not sure if the audiences include broader people, like coreboot, SBL developers, > do they like the names. > > Personally I am open to any name as long as the concept is not changed: the binary blob > is responsible to initialize the silicon. > > >> >> >> (2) What is the *exact* use case (or workflow) that the proposed >> interface enables, or improves? >> What groups of people (what roles) are supposed to benefit from the >> proposed interface? > > 1. Unified UEFI Payload Binary. > By standardizing the bootloader->payload interface, we keep in mind to move all > platform/silicon specific implementation to bootloader and all the specific info is > passed to payload through the standard interface such that the payload doesn't need > to deal with concrete hardware but just the abstracted info. It gives possibility to create > the unified UEFI payload binary that can run in any platform/silicon (off course, one binary > per one CPU arch). Just like today's UEFI Shell. > It's a huge save on validation side to every company that uses UEFI as boot solution for > hardware. > People may argue maintaining such a binary causes additional overhead. I agree. > But I am optimistic on such direction. > (The code will be still in open source.) > > 2. Bootloaders > It shows an attitude of EDKII community that it doesn't restrict to use EDKII PEI as the > only acknowledged silicon code execution environment. The standard interface as a promise > allows any compliant bootloader to work with EDKII UEFI Payload. > > 3. Payloads > I saw different tries to change EDKII DXE environment for different hardware/OS. > It may cause defragmentation of UEFI spec. The standard interface also allows any > compliant payload to be created. - I don't have anything against this, as long as existent platforms are not required to adopt the new scheme. - The above description helps, but it is *still* too generic for me to understand: (a) Intel already distributes Firmware Support Packages, which are supposed to deal with RAM / chipset initialization, AIUI, (b) the PI spec is not tied to edk2 PEIMs, and I don't see where EDKII PEI modules are currently the only "acknowledged" silicon init environment. The edk2 tree itself seems to contain platforms that don't use the edk2 PEI module set at all, but (IIRC) jump from SEC to DXE. I believe "ArmPlatformPkg/PrePi" and "ArmVirtPkg/PrePi" are related to this. (c) Replacing edk2 DXE should already be possible without replacing the edk2 DXE IPL PEIM -- isn't it enough to change the contents of the boot firmware volume? I haven't looked at the above interaces in detail for a very long time now, but I feel we already have the necessary abstractions in place. So clearly they are insufficient for *some* workflows / use cases. That's what I'd like to understand more closely. What are the specific problems with the edk2 offerings? Can you describe example activities that vendors or other stakeholders would like to perform today, but they can't, or at high cost only? I'm quite "out of the loop" on how firmware is composed *in practice* for proprietary / binary-only / multi-vendor platforms. With my background in OVMF, I could be missing your point-of-view entirely. Which is why I want to say very clearly that I'm not attempting to "block" this proposal at all -- as long as it causes neither regressions, nor new requirements, for existent platforms --; I just think the limitations of the current interfaces / implementation, and the desired improvements, should be written up precisely. Case studies, actual projects etc would help. (I understand that you referenced actual code already, but I don't have capacity for reviewing code, without an actual use case for OVMF. Hence my request for a natural language description.) Thanks Laszlo