From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D1441C433EF for ; Tue, 12 Jul 2022 04:33:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B21CC8408D; Tue, 12 Jul 2022 06:33:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="QoJuMyO8"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 453CB8409B; Tue, 12 Jul 2022 06:33:08 +0200 (CEST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 702C284072 for ; Tue, 12 Jul 2022 06:33:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jwerner@google.com Received: by mail-wr1-x429.google.com with SMTP id z12so9473862wrq.7 for ; Mon, 11 Jul 2022 21:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7nRcYQffcg6Nfvu+G0BbM98nz5nTB2v7fDLcUaynP/Q=; b=QoJuMyO8Q3TfNhLnCclEBYiZehvyS++QY6wqV4seGl4OkHUknHvk+tuWGT62L9mul7 ztiRgJix+TDH8k+xXsOEYsUHKC7BwCpGdvYcCJgqQb/rwHYR0vdzg1TH/92yJ/FclRYu tm6H83czPe63T1JKWbBpyxxQ4waH2hj7TwwNU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7nRcYQffcg6Nfvu+G0BbM98nz5nTB2v7fDLcUaynP/Q=; b=YEJAJiQ9LeTAiGmRfJ/rjtLfE9VNM6hcoXGA2hrzJFwltqlr9vHCz+gxxGOacF+mqv td6DNGq0ew/40NzEkp+TIrDdQT7dlDbIZ3gm/LKWu5I3lQ+4dhtdmHXkm9q5w8AHatdH sGjNmGO7REAvGah5z6w3xeG5IjcvSBXSCaHm8EQbtgu0gh45T3FuRUKLAmS96In5D14l RLCQd96XPU/T6qyrsrIFY+m1RWLzS+Ai4e8hfrFrQ9PuiScVsHH/y89Lyl/yvFXGYpHf WNhmkxHnFEzu0GFC2QGh5uKf4UpAnRMS0uEeLLToT8L3g86Obe8DudjJbp3U1tygu7EC 0zIw== X-Gm-Message-State: AJIora+s1z4yw3Wdd6j2RyK3bvSl4nn7S65CHr75LGXJV2rqwhNmSphF Ee2tgVTcgxtRDkYxuj5txUEIFttQ2Qp9xnHW265tfA== X-Google-Smtp-Source: AGRyM1vyztHK23KByUy0MUAvJpcwSPyoB41XuWTSGKR4fMgwT2dhMoZ6LFjjJ9w47fQW5PMKVQRNDEtMFXTe7H3moyw= X-Received: by 2002:a5d:61d0:0:b0:21d:5e08:af3c with SMTP id q16-20020a5d61d0000000b0021d5e08af3cmr19618023wrv.25.1657600383657; Mon, 11 Jul 2022 21:33:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Julius Werner Date: Mon, 11 Jul 2022 21:32:49 -0700 Message-ID: Subject: Re: [TF-A] [RFC] Proposed location to host the firmware handoff specification. To: Jose Marinho Cc: Julius Werner , "tf-a@lists.trustedfirmware.org" , "u-boot@lists.denx.de" , "boot-architecture@lists.linaro.org" , Manish Pandey2 , Joanna Farley , Ilias Apalodimas , Simon Glass , Matteo Carlini , Dan Handley , "Harb Abdulhamid (harb@amperecomputing.com)" , Samer El-Haj-Mahmoud , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean > That draft is the DEN0135 document [2]. > I realise that I haven=E2=80=99t made it sufficiently explicit in this th= read that the DEN0135 document [2] is still at draft quality (see ALP matur= ity called out in the title page and footers). > Please do not consider this a finished document =F0=9F=98=8A. We=E2=80=99= ve been iterating on this pdf as we gather feedback from the open-source co= mmunities. > It's becoming clear that we need to move this debate to a more suitable f= orum. > That=E2=80=99s why we=E2=80=99re proposing, in this thread, to move the d= ocument to trustedfirmware.org. Understood. FWIW, I totally support hosting this on TF.org, I think that makes sense considering that it has good co-development infrastructure that is open to everyone (e.g. Gerrit) already set up and that it's easy to administer for you guys who are currently organizing this. I don't really see Simon's concern regarding "captive to one project" -- this whole spec is an attempt to cooperate better, not work against each other, so there shouldn't need to be fights about who "owns" it (just pick a place with good infrastructure and let everyone access it there). If perhaps the real concern is rather related to who controls future spec updates, tag assignments, etc. then I think we should address those directly and define clear processes that we can all feel comfortable with, rather than implying that the final word on these is left to whoever controls the hosting platform. > The requirement originated in feedback from the u-boot community, please = see [3]. > The argument for 16-byte alignment is that some data-structures have to b= e 16-byte aligned. > We ought to meet that requirement if we ever want to carry those structur= es. I still really think that this is wasting space to the point where it defeats the purpose of this being a "lightweight" data handoff structure. Consider that all of the bl_aux_params tags in TF-A (which I described as one of the existing mechanisms for this kind of thing in last year's thread) are 8 bytes or less, which means that for these use cases the transfer list would have over 3 times as much overhead as actual data. There seems to be some disconnect here since the stated idea for this is to be a lightweight handoff mechanism to pass individual pieces of information directly, yet all the initially proposed tags are just for wrapping large existing hand off blobs that bundle lot of information in their own structures (giving it a very xkcd.com/927-like feel), and the spec design seems to be tuned toward the latter use cases. If individual tags have special alignment requirements, they could just deal with that internally (by including another offset field in the "data" part) without dragging every other tag in the structure down with them. Alternatively, if you really want to keep this I think an acceptable compromise could be to keep the 16-byte entry alignment but reduce the transfer entry header size to 8 bytes, and then allow tags that don't require 16 byte data alignment to immediately use the following 8 bytes for data. That way, entries with 8 bytes or less of data could fit both header and data into a single 16 byte block which drastically cuts down on overhead for small data. > > 2. The table entry header seems unnecessarily large. What's the point o= f > > including a "header length" field when that field will always contain a= 16? > > The "header length" enables the table entry header to be extended if we e= ver need that in the future. > Changes to the TE header are backwards compatible. > A consumer obtains the address of the data by adding the "header length" = to the entry's base address. I really don't see this as likely enough to be worth paying that big upfront cost of making the whole structure so much less efficient to start with. I think 8 bytes are already the most you'd reasonably want to pay for header overhead, I find it highly improbable that we'd want to introduce more fields later to make that even bigger. If there's desire for optional large annotations (e.g. per-entry cryptographic hashes) in the future, I'd rather suggest implementing that as "companion entries" with special tags that are written right behind the entry they refer to, rather than try squeezing it all into a single header structure. If you want to leave some room for simple bit flags, I would suggest masking out the high byte of the data length field instead (i.e. splitting it into 3 and 1) -- it doesn't seem like anyone would want to pass a data item larger than 32 MB in a firmware information structure anyway. > The TL header version is incremented when we do a new release of the docu= ment. > At a new document release, we can introduce one or more new standard tags= and also append fields to the TL header. FWIW I would suggest decoupling the data structure version from the document version and only increasing the data structure version when the actual structure changes in a meaningful way. Documents may be amended to improve clarity or add more detailed explanations that don't always require parsers to actually act differently, so increasing version numbers in the code for those cases would seem to just unnecessarily confuse things. > > 4. I don't think a strict definition of entry type ranges is a good ide= a, > > particularly if "standard" and "OEM" are the only two options. > > As mentioned above, the standard tag range ought to have a low-barrier fo= r new tags to be requested. > The OEM range allows FW integrators to carry platform-specific entries th= at may not be generalizable. Okay. This definitely needs to be specified in more detail and give more guidance about where tags should be allocated for what case, because my first impression from reading the doc was apparently quite different than yours. I think the spec should strongly encourage allocating a global tag whenever there might be the slightest possibility that other platforms might want to use it later. For example, maybe we can define the guideline that anything referred to by any code checked into the upstream of any open source project (U-Boot, TF-A, whatever) should always be a global tag. I guess a small range of OEM tags makes sense for closed source downstream code that isn't shared with anyone, but that should be the only use case for that (so that open source projects can always freely collaborate and adopt each others' standards without the risk of tag clashes). > The feedback we received so far is: data should be included in the TL as = that simplifies procedures, such as relocating the data, without having to = worry > about stale pointers. I generally agree with that sentiment, but I also don't see including a whole FDT or ACPI table in this structure as a normal case -- that's more of a pathological edge case necessary to interface with environments that use these other hand-off structures (because all these are really just different ways to do the same thing, and there's no real benefit from wrapping one in the other... it's just an unfortunate necessity due to different boot stages expecting different things). I really expect these to be mostly independent (and come with their own placement requirements, which is a problem for direct inclusion), I would expect at least some platforms to need the flexibility of keeping them separate and therefore think it would be better to standardize on that. But if other platforms really think it's important to have these inline in the transfer list for their use case, you could offer separate tags for both.