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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67FD1C433F5 for ; Thu, 30 Sep 2021 05:12:09 +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 511AC6142A for ; Thu, 30 Sep 2021 05:12:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 511AC6142A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 96F5280EFB; Thu, 30 Sep 2021 07:12:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PcSCPqHR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 49AFB80F1A; Thu, 30 Sep 2021 07:12:04 +0200 (CEST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 5394F80D2E for ; Thu, 30 Sep 2021 07:12:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=bmeng.cn@gmail.com Received: by mail-yb1-xb2e.google.com with SMTP id b82so10483009ybg.1 for ; Wed, 29 Sep 2021 22:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yuGuKFS7WZBLMK5OH+xN/hAIxbKf2f7TGr08LZ4zaw0=; b=PcSCPqHRe5R2rkcUxn0uTeKi59vV02KF6JX6YUeLdwn0RvUTxMb+GAPZOjcdFQF3IK U/wzP95BqMjzPFqPJWzwFqbbxEbmZFbBkGSqvCM45iS2OcHjpuxz7LS7Swm5gCqmUChT l5xfLaKmMMmupgVGbytzJB1sUNwWETsCRMUckKyVMw53HdGposQXRTeTrYi2B8RKhbnh 2NGmYuEHxlr24G/DqBQilFasrrlqTT6y+sODj0BCZNtqmFBst4BMe5N3yE7EQFNYOCrT UJ335iqd5c/zoFN99tUa1aNEQyuy4NoT8cUMEiCJ8myOuZc44Zed+ZizaCTFHSzlvUGI CKPw== 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; bh=yuGuKFS7WZBLMK5OH+xN/hAIxbKf2f7TGr08LZ4zaw0=; b=F9t2xWQdrVGhHNa7kZ5hj1roj4pZ6th5ZtEYHKzKu15SvjAJeSrrBtb2vcai6GAmsC GKgKJhKwZAhh1WmSRtinV1o26lsmRIbx8bgSKsj93xfDz1FwYuPoQFNXz63nKdqJfHAK PwQISZXs/oLUx1nl4Gw9TV8jozXSa2wqdS/dcf/vR/ebX9omFIuoInMUcj4dskYZhVRL hJUBpw4NKA83w/M4eYlr8WqheZRwtjL5CG3eA/7f/7rE6wZPOPCrH+/gydeP+qZJMI5O enXkcQeGWhGmlmNTvgr6xwidDVgmfhcD83B34kaTqfFLsNyngwYcCMAZisX26z5mKoxN m+1A== X-Gm-Message-State: AOAM531hYO00GNjA2eX2YxkaN9uDxGk5wfpcF4l9qfqcZkR7gEjZoRMM tFHuNG+BCi0EgRE21AL49jNaHdMBS+n10NtKQtg= X-Google-Smtp-Source: ABdhPJz5l8q8S0l+4fQjL853Qowz1hudxu6H4IrJ9KRT4IYD2kI1EUXUkgvrMM2HvJz3Cqvc2rz/ye9q1VydgovgJ0w= X-Received: by 2002:a25:d48f:: with SMTP id m137mr4193356ybf.109.1632978719090; Wed, 29 Sep 2021 22:11:59 -0700 (PDT) MIME-Version: 1.0 References: <2461183e-ae0a-d8b3-3822-6a06ee90950d@gmx.de> In-Reply-To: <2461183e-ae0a-d8b3-3822-6a06ee90950d@gmx.de> From: Bin Meng Date: Thu, 30 Sep 2021 13:11:47 +0800 Message-ID: Subject: Re: Driver model at UEFI runtime To: Heinrich Schuchardt Cc: Simon Glass , Ilias Apalodimas , U-Boot Mailing List 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 Hi Heinrich, On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt wrote: > > Hello Simon, > > The EBBR specification requires that the UEFI SystemReset() runtime > service is available to the operating system. > > Up to now this has been implemented by overriding function > efi_reset_system() which is marked as __efi_runtime. > > Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM > and the System Reset Extension for SBI on RISC-V. This has kept the > number of implementations low. The only exceptions are: > > * arch/arm/cpu/armv8/fsl-layerscape/cpu.c > * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs > * arch/sandbox/cpu/start.c > > Bin has suggested in > https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use > reset drivers based on the driver model. > > Currently after ExitBootServices() the driver model does not exist anymore. > > When evaluating Bin's suggestion one has to keep in mind that after > invoking ExitBootServices() most operating systems call > SetVirtualAddressMap(). Due to the change of the address map all > pointers used by U-Boot afterwards must be updated to match the new > memory map. > Yeah, this was discussed 3 years ago: https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken > The impression that Ilias and I have is that keeping the driver model > alive after SetVirtualAddressMap() would incur: > > * a high development effort > * a significant code size increase > * an enlarged attack surface > > For RISC-V it has been clarified in the platform specification that the > SBI must implement the system reset extension. For ARMv8 using TF-A and > PSCI is what ARM suggests. > > So for these architectures we do not expect a growth in the number of > drivers needed. > > Ilias and my favorite would be keeping the design as is. > > What is your view on this? Is U-Boot's UEFI loader implementation supposed to be the recommended UEFI firmware on ARM and RISC-V on a production / deployment system? Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we expect to load grub.efi which chain-loads a kernel without CONFIG_EFI_STUB? What do distributions normally do? What's our position when compared to EDK II? Regards, Bin