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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76C34C433EF for ; Sat, 4 Dec 2021 01:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BVmYKMKTwxZkP+mzKYmjZurzX9OP1WP5/KGML4vhWw0=; b=OeF5LmV7SfK6sY 40Q4WOeY/Myj8QkaLh7DTiQjk0naky12OXqn/X8ke23Z8m4lWR9l0EVa5aZGJKQvZ8q7jWe4eLsLg 9LmOBtLtMhnU+nxHHmHiV7SdNLPlq/Ueu9dL8yeXBaw39cB8lzuV8BIvAFdiWcZu3GYrVYm8LOH9j YtfcaNl9dPqtvrXU5j6OWLkZHqKhj3kj/xWe7RSujdwhzeG8+UrMCsp0MyKwah3x+pqXiZdHh0UWk QCOJPuAEnkGVusqhENJz7P6ZdJrlwWWnbw/Lza7/2EJn+xRwIlFeseDVVrAkEEYp9gSZr2xrRhpH5 zRDp8Eq9ES+4ZT6+wbAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mtK9Y-00HOke-N7; Sat, 04 Dec 2021 01:47:52 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mtK9V-00HOjc-Jt for linux-riscv@lists.infradead.org; Sat, 04 Dec 2021 01:47:51 +0000 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (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 smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 3E94D3F1BA for ; Sat, 4 Dec 2021 01:47:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1638582465; bh=CazNEo34UzEVreoekwSVYqsHxJj65p3DlJkHSNGX3Uc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=vD3OEe4/+NaByRABubtm3qGcLpOrhfpJ7lD5/dbJgPC4d0lKznkQzSR4lJPnsaxO2 dzROQOJWxCWqc7xUqDrK9G+RW514KvN1DEsfUHr96tXEGHtUtFQtApKLCJlZTd5x0T JHOBOFwoPwQ4xo2vEHJF7LG2WRrJ5CKPiFC26QUyrDsfw8d9Q/w1QAVxuhUi4agLh5 wK+ixscbu7FZMREJgOGH/uqkwQOCmJg+nP/6np+Pdo2aHHivzf9ogfnokDKuPVQZXZ 94ir9pqxn1bPaam72qUUg3Qu4ufy3Rl82U3Va8t4goCGSBQTnHbbCFD+6jwLeMI6AH ngJygpPr4MXBg== Received: by mail-wm1-f69.google.com with SMTP id 69-20020a1c0148000000b0033214e5b021so2427709wmb.3 for ; Fri, 03 Dec 2021 17:47:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=CazNEo34UzEVreoekwSVYqsHxJj65p3DlJkHSNGX3Uc=; b=dqcvgLz7Y+rODnzrXMpcsEQZ93SWIaw7b3K9aIrAllNIpUIfXjXad1IxqQwxDzmf9E Q4XlPnihRkfBKMzzhCeFItzYiBEXirwlOMDK5fCz+5mbYr8+SXRAm3Kx2siy+CV57RJs hUNYBnonClZRs8LDFGGBXMnL8Sc1wddf4jkuFA1PuhPY1Beo8aEiyt0MyrYMI5WF+aG5 eLJllfu4Kh8XKYOKW35PlvlvFFxpXDbp3hOeaJjSI6KRFXiE68+YQMYDR7VT+fRARqxp Fop90QfLz/pJB2uNhy2gzFDzU3JjyWPI3CIxGMV6qMfd5WF8Fu8JKMn4X7s/4FE4RKU0 6qCQ== X-Gm-Message-State: AOAM5303W8I8BJIl29Ad5WJ0JYaj4GcAlno+SGjBSnn9ZIv3jkYwUP/B By/xIFZXgHY0tFXiRBb5OGdhZ6qXiuTpafbg1lwSRLL2lxbK+6x84IO7FpRmH1/Y86fvmKtlhHY wDRUX7gt33ifMTh3zGzmlafIYslRvzCIRCa2aqiaFhb9Hng== X-Received: by 2002:a5d:4523:: with SMTP id j3mr25693175wra.185.1638582464789; Fri, 03 Dec 2021 17:47:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJzAAna/E3qcfwPt8WocTayajAgpperBOBFfF4i4b5Z3HaN0yvpvflGvYu/4XuPRTBgZRjQ0uw== X-Received: by 2002:a5d:4523:: with SMTP id j3mr25693145wra.185.1638582464536; Fri, 03 Dec 2021 17:47:44 -0800 (PST) Received: from [192.168.123.35] (ip-88-152-144-157.hsi03.unitymediagroup.de. [88.152.144.157]) by smtp.gmail.com with ESMTPSA id o9sm4109457wrs.4.2021.12.03.17.47.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Dec 2021 17:47:44 -0800 (PST) Message-ID: <7416157e-50d1-3664-7df0-2a45e29cd8c1@canonical.com> Date: Sat, 4 Dec 2021 02:47:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Question regarding "boot-hartid" DT node Content-Language: en-US To: Atish Patra Cc: Abner Chang , Heinrich Schuchardt , Jessica Clarke , Anup Patel , Palmer Dabbelt , sunil.vl@gmail.com, linux-riscv , Sunil V L , Ard Biesheuvel References: <20211202150515.GA97518@sunil-ThinkPad-T490> <89d42547-ec36-5f84-88d1-fd65d891488c@canonical.com> <6d9f131d-b3e8-18df-a9b6-6aaac881eb65@canonical.com> <6fccad4e-b579-25ed-6bf3-2fb2a968b243@canonical.com> From: Heinrich Schuchardt In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211203_174749_927163_6DB334A3 X-CRM114-Status: GOOD ( 52.17 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On 12/4/21 01:44, Atish Patra wrote: > On Fri, Dec 3, 2021 at 10:45 AM Heinrich Schuchardt wrote: >> >> On 12/3/21 11:53 AM, Heinrich Schuchardt wrote: >>> On 12/3/21 11:13, Ard Biesheuvel wrote: >>>> On Thu, 2 Dec 2021 at 20:29, Atish Patra wrote: >>>>> >>>>> On Thu, Dec 2, 2021 at 9:05 AM Heinrich Schuchardt >>>>> wrote: >>>>>> >>>>>> On 12/2/21 17:58, Ard Biesheuvel wrote: >>>>>>> On Thu, 2 Dec 2021 at 17:53, Heinrich Schuchardt >>>>>>> wrote: >>>>>>>> >>>>>>>> On 12/2/21 17:20, Ard Biesheuvel wrote: >>>>>>>>> On Thu, 2 Dec 2021 at 16:05, Sunil V L >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> I am starting this thread to discuss about the >>>>>>>>>> "boot-hartid" DT node >>>>>>>>>> that is being used in RISC-V Linux EFI stub. >>>>>>>>>> >>>>>>>>>> As you know, the boot Hart ID is passed in a0 register to >>>>>>>>>> the kernel >>>>>>>>>> and hence there is actually no need to pass it via DT. >>>>>>>>>> However, since >>>>>>>>>> EFI stub follows EFI application calling conventions, it >>>>>>>>>> needs to >>>>>>>>>> know the boot Hart ID so that it can pass it to the proper >>>>>>>>>> kernel via >>>>>>>>>> a0. For this issue, the solution was to add >>>>>>>>>> "/chosen/boot-hartid" in >>>>>>>>>> DT. Both EDK2 and u-boot append this node in DT. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think this was a mistake tbh >>>>>>>>> >>>>>>>>>> But above approach causes issue for ACPI since ACPI >>>>>>>>>> initialization >>>>>>>>>> happens late in the proper kernel. Same is true even if we >>>>>>>>>> pass this >>>>>>>>>> information via SMBIOS. >>>>>>>>>> >>>>>>>>> >>>>>>>>> It would be better to define a RISCV specific EFI protocol that the >>>>>>>>> stub can call to discover the boot-hartid value. That wat, it can >>>>>>>>> pass >>>>>>>>> it directly, without having to rely on firmware tables. >>>>>>>> >>>>>>>> As discovering the current process' hartid is not a UEFI specific >>>>>>>> task >>>>>>>> SBI would be a better fit. >>>>>>>> >>>>>>> >>>>>>> I disagree. The OS<->loader firmware interface is UEFI not SBI. So if >>>>>>> the EFI stub needs to ask the firmware which boot-hartid it should >>>>>>> pass in A0, it should use a EFI protocol and nothing else. >>>>>>> >>>>>>> Whether or not the loader/firmware *implements* this EFI protocol by >>>>>>> calling into SBI is a different matter (and likely the best choice). >>>>>>> But that does not mean the EFI stub should make SBI calls directly. >>>>>>> >>>>>> >>>>>> The EFI stub does not need the boot-hartid. It is the main Linux kernel >>>>>> that does. And that kernel already implements SBI calls. >>>>>> >>>>>> The main kernel could just try to read CSR mhartid which fails in >>>>>> S-mode >>>>>> and the SBI could emulate it. >>>>> >>>>> New SBI extension should be added only if there is no other way to >>>>> solve a generic >>> >>> I am not sure this feature would be implemented as SBI extension or as a >>> CSR emulation. Cf. sbi_emulate_csr_read(). But anyway it would require >>> an update of the SBI specification. >>> >>>>> problem. The boot hartid issue is very specific to efi booting only. >>>>> Any system that doesn't require >>> >>> The boot hartid is not EFI related at all. A firmware running single >>> threaded does not need this information. >>> >>> Information about the boot hartid is a general OS need. >>> >>> I am wondering why S-mode software should not have a generic means to >>> find out on which hart it is currently running. >>> >>>>> EFI booting won't need it. Even for EFI booting, we have other >>>>> approaches already proposed >>>>> to solve it. That's why, SBI extension should be the last resort >>>>> rather than first. >>>>> >>>>> I think an RISC-V specific EFI protocol as suggested by Ard should >>>>> work for all the cases. >>>>> Is there a case where you think it may not work ? U-Boot & EDK2 >>>>> already stores the boot hartid. >>>>> They just implement that protocol and pass the hartid to the caller. >>>>> We do need to support it in the grub though. >>>>> >>>> >>>> Why would GRUB care about this? The EFI stub will call into the >>>> underlying firmware to invoke the protocol, GRUB is just a loader with >>>> a fancy menu that allows you to select which image to load, no? >>> >>> This is a related discussion: >>> >>> https://github.com/tekkamanninja/grub/commit/be9d4f1863a1fcb1cbbd2f867309457fade8be73#commitcomment-60851029 >>> > > Yes!! Thanks for refreshing the memory. It seems after 2 years, we are > still debating the same topic :). > Let me summarize the thread. There are multiple ways for EFI stub code > to retrieve the boot hartid. > > 1. EFI variables - This is what Henerich proposed last time. Ard > suggested that EFI configuration tables are better candidates than EFI > variables. > 2. DT modification - This was preferred over the configuration table > at that time given because RISC-V was DT only at that time. > We already had all the infrastructure > around DT. Thus, DT seemed to be a natural choice then. > It works now for existing setup > however, the DT approach will not work for systems with ACPI support. > Adding a similar entry in ACPI tables > is possible but adding ACPI support in EFI stub is not trivial. > 3. SMBIOS - Only for platforms with SMBIOS support. SMBIOS is not > mandatory and adding SMBIOS support in EFI stub is not trivial. > 4. SBI - As I mentioned before, this is an EFI specific > problem because EFI stub doesn't know what the boot hartid is. Thus, > it should be solved > in an EFI specific way. An SBI extension for > such features may not be acceptable as the non-EFI booting method > works fine without the SBI extension. > 5. RISC-V specific EFI configuration table or protocol: Ard suggested > EFI configuration table last time. Earlier in this thread, EFI > protocol was suggested. > My personal preference has always been one of > these as it solves the problem for all EFI booting methods > for platforms-os > combination(DT/ACPI-Linux/FreeBSD) in an EFI specific way. > > @Heinrich: Do you see any issue with the EFI configuration table or > protocol to retrieve the boot hartid? There is nothing technical stopping us from implementing either option. We could simply reuse the EFI Device Tree Fixup Protocol (https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL) implemented in U-Boot and already used by systemd-boot. Pass a devicetree (which may be empty) to the Fixup() method and it will add the /chosen node with the boot-hartid parameter. The EFI stub anyway creates a new device-tree to pass the memory map to the kernel in the ACPI case (function update_fdt()). Calling the EFI Device Tree Fixup Protocol could be easily added. Best regards Heinrich > > My only concern with the RISC-V EFI protocol is that Ard suggested it > doesn't need a modification in UEFI spec. > Where should we document it in this case ? We can't document it in > Linux or EBBR. > Because, this is a protocol that server systems and other non-Linux OS > will also use. > We can define it in the RISC-V platform spec. But that's not the usual > place where somebody will look for the definition of such protocol. > > Wouldn't it be better to standardize it in UEFI spec ? The UEFI spec > already has ARCH specific protocols/config tables. > >>> >>> If GRUB loads a devicetree it will anyway have to call into the firmware >>> for fixups. These will include adding the boot-hartid. >>> >>>> >>>>> @Heinrich Schuchardt >>>>> I vaguely remember you proposed something similar when we discussed >>>>> this first during FOSDEM. >>>>> I can't recall why it was abandoned in favor of the DT approach which >>>>> works. But, >>>>> it is not an ideal solution considering RISC-V ACPI support is already >>>>> on the way. >>>>> >>>>> Do you have a link to the older thread where this thing was discussed ? >>> >>> Unfortunately I cannot find anything. >> >> I assume Atish referred to this thread: >> >> https://patchwork.ozlabs.org/project/uboot/patch/20200205055334.4072-1-xypron.glpk@gmx.de/ >> >> Best regards >> >> Heinrich >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv