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 X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8341C636C9 for ; Fri, 16 Jul 2021 02:23:38 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 628E1613E0 for ; Fri, 16 Jul 2021 02:23:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 628E1613E0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CEF0F81668; Fri, 16 Jul 2021 04:23:34 +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="N9n6kg5T"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 54B4481E53; Fri, 16 Jul 2021 04:23:32 +0200 (CEST) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 411D981664 for ; Fri, 16 Jul 2021 04:23:29 +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-yb1-xb2a.google.com with SMTP id x192so12365973ybe.6 for ; Thu, 15 Jul 2021 19:23:29 -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; bh=DQ47FK6In0Ze4sh2Yqr/OMNP94V2o/KIzcu0lvkiJbA=; b=N9n6kg5Tj5+Gm4pXCVzuISWAv3aivatTnnMqSXIF4kIs7eyy0I3htRu9FESMykzmRY fdrXYZgHE03eb6Q8gvnEc2g9k+H9r/vox1T5OJlD1tBCaPHEZUNWGpCuPVeN+SSubIrA Zd634WuMwNVat9XpO+6Z0cqxeLTEQncj9Nwm0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DQ47FK6In0Ze4sh2Yqr/OMNP94V2o/KIzcu0lvkiJbA=; b=bcLZRXzWvYF5utEf/Pf7yBTj+NfpzRRmYtKehOjoj1S+RWnO+3QUbBa5SRz0TbWGVJ S9zXFCPtAaSVotD2vkB1riJbv+msrI9R97jlRqkRNzVG0H3Ulz7xkYcbe9IUOflIeys4 IzukO4GYo0QNVgijk4JaGjSvdxlw+7QwzeJ8ZTif2Ql7yYRr0mpqL1UUnApUcw2IlW7q o8G966xjiS5OcM9c73Bljk55tNLs8tAKKAB1ehKCatjWm6UeKOy7+uW9wsPDju83ouOv Iz7lMBrbtTiqJKOC2d72wrz0YgTu3rQw5ksFfIZEuewnrbq/h6aNbiSUho0VzZVMfq6z 2WPQ== X-Gm-Message-State: AOAM530jYfzu8Ci6Miliq7ZeVnT+4kJG8+YZmaySdj02Lr1xhH3X5l3G VGScolLIxcVMO0D8ukaZ4mQptwwunmQ24Owob0VGYA== X-Google-Smtp-Source: ABdhPJzs9KdgCBXkY38oEZERaEQkkGSjtfhNimZzIzzqZouOpLftuQve7Tb1H/wN5EtxFgeejm+MAHCn+KuK3p1TKvQ= X-Received: by 2002:a25:34d1:: with SMTP id b200mr9026255yba.492.1626402207641; Thu, 15 Jul 2021 19:23:27 -0700 (PDT) MIME-Version: 1.0 References: <10CCF05B-96E6-4C92-942F-1B4C774A813E@arm.com> <0100017a8648f3d5-98a3bce6-b2dc-48cb-84e4-c292bcef5622-000000@email.amazonses.com> <20210709100732.zynd3qkwqjamb5qm@maple.lan> In-Reply-To: From: Julius Werner Date: Thu, 15 Jul 2021 19:23:15 -0700 Message-ID: Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages To: Simon Glass Cc: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Julius Werner , Manish Pandey2 , Daniel Thompson , Ed Stuber , Boot Architecture Mailman List , undefined , Harb Abdulhamid OS , Arjun Khare , U-Boot Mailing List , "tf-a@lists.trustedfirmware.org" , "Paul Isaac's" , Ron Minnich , Moe Ammar Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean > - fuller implementation with more features Is that a good thing? Didn't we just have a long discussion eschewing a heavy-handed, bulky hand-off block design in favor of more simple and flexible structures? I think simplicity is key for this and the bl_aux_params are trying to be about as simple as they can possibly get. Particularly in a situation like this where many different projects will need to implement this independently, any extra clutter (like versioning, an apparently unused(?) flags field, checksumming) adds unnecessary extra friction that's best to avoid. (You can *do* all these things like adding an extra checksum over the whole thing with bl_aux_params by just defining an extra tag for it, of course, but none of them are required for platforms for which they don't make sense.) > - has comments / more documentation Is there anything in particular you feel is missing from the bl_aux_params comments? > - easily supports everything in one block instead of a linked list (easier to allocate) I don't understand how this is easier, in fact I see it as a big drawback. The bl_aux_params design allows structures to be allocated wherever -- in the easiest case you can just define them as global variables in the earlier stage (in the respective files that deal with each tag) and then chain those together. You *can* of course also allocate them in a contiguous block from a special memory area, and if you're planning to pass this across more than one stage boundary that's probably the better choice. But not all platforms have that requirement, and this design allows them the flexibility to choose. The coreboot platforms only care about the BL2->BL31 transition, so why should they switch to a design that forces us to set up an extra contiguous-block allocator for no good reason? > - avoids 64-bit tags/size which seem quite unnecessary Well, earlier there were some concerns about possible tag collisions, so I think the extra space doesn't hurt to alleviate those fears. Having 64 bits allows us to split the tag space into many separate ranges that can then be allocated from independently -- for example, we could just say that the top 2^63 tags are available for private vendor tags generated as random numbers (like a GUID). (Your bloblist seems to waste space on things like a "spare" field instead, so in the end both implementations still come out to the same overhead per tag, and bloblist has additional overhead for the header at the front.) > - ability to link to another bloblist (do we really need this?) FWIW you can do this by default with bl_aux_params because they're not required to be contiguous.