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 1CEF3C38142 for ; Tue, 31 Jan 2023 14:49:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2AC9985A9B; Tue, 31 Jan 2023 15:48:59 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.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=canonical.com header.i=@canonical.com header.b="ejrKVHDt"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F415185A1A; Tue, 31 Jan 2023 15:48:55 +0100 (CET) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id BDAA185A1A for ; Tue, 31 Jan 2023 15:48:51 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=heinrich.schuchardt@canonical.com Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (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 1E1E741ACB for ; Tue, 31 Jan 2023 14:48:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1675176531; bh=sQUamfXidd40qOAH4atzELBrxQZYHgV2SzTy06qc7v8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ejrKVHDt/6lkFBdJ44ZxGGXBZioYKacTu/GL+lkaAqLSHm+GxXZZyx5ZMEPTL3562 1VTBrFokyIiM4zILH6GVSO3gCDf5j2QVHT5oDRCbq1SeOeEDzDct4xfgLKBaUVv9Ng ndKszuV4hIS/zgWzwzZV8z/uyoKRM0X5Tu2uXYTi65/Isj6CGgLcxKHtNA3TpBf5cT Gi0sqLRdDvAmQ1fDjP10vli6SZmil0j5hOzDsRAiCn/beOgkTZi4GMH32ucpwZlKBt 7YstP29ogkIbSv7JLdPfddmFSOtHnbdX04BdlOPHdEdeGwlMMBFzsOi/FwrdbX78KI ZpoldWTb3H/VQ== Received: by mail-wm1-f72.google.com with SMTP id iv6-20020a05600c548600b003dc4b8ee42fso5293369wmb.1 for ; Tue, 31 Jan 2023 06:48:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sQUamfXidd40qOAH4atzELBrxQZYHgV2SzTy06qc7v8=; b=PLt1DU6cFVAMNCwsxSctoekDLuTnXY4vcK9gtpewd+wJMGdMKjJ390iYhXR4BzCH9E GczP7kbr5X2O1wnd52jeXkDuh621vkR9yAOAX4RQ4C6Zcgsvc4mLCtlnWzetSQFXSAOi NeMnnIg+tLnawErdMv17KdCg+86nQ7R0/eepRBH0xPb7og/RRDEoLjBeYDzU+rlNY6oM 6euPi2TLdBlf+/oOID1hR0KCHRBXlNZStKVUhFw2Eo/DQNkP85XQvG9RhdOY1S4+hc9O T3zfMBoRllR+Cin3yeOX6ybctwEV3QcK95M0qFZ1TsMYaSG5f+k4zyGBufAYmnekJjmi Jr4Q== X-Gm-Message-State: AO0yUKVAevQI03Ui9t2WxfVJCQi2reJwZK7yGp5zwWDeh9zcTCCMCmqQ KSw1skh+dFKSbvzBpLF3CUsURUCMillTeGd4ktADD/jwat9j3NKP+FX9fTU3a+j1dJmuAeCI1da 7KjTc6uv3Er6ymE1uXfslRCDkas/aGIQ= X-Received: by 2002:a05:600c:458a:b0:3dc:45a7:2b8a with SMTP id r10-20020a05600c458a00b003dc45a72b8amr13276510wmo.10.1675176530753; Tue, 31 Jan 2023 06:48:50 -0800 (PST) X-Google-Smtp-Source: AK7set/2FZ8BM1Xl48GmJqSVff7GoY8Hfuo9ktMi3EWTl+rucSi7QqOz/5w2pv++x0qM5hDnGj8vMg== X-Received: by 2002:a05:600c:458a:b0:3dc:45a7:2b8a with SMTP id r10-20020a05600c458a00b003dc45a72b8amr13276488wmo.10.1675176530446; Tue, 31 Jan 2023 06:48:50 -0800 (PST) Received: from [192.168.123.67] (ip-088-152-145-137.um26.pools.vodafone-ip.de. [88.152.145.137]) by smtp.gmail.com with ESMTPSA id o16-20020a05600c379000b003dc49e0132asm10667574wmr.1.2023.01.31.06.48.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Jan 2023 06:48:49 -0800 (PST) Message-ID: <0dc24836-959c-25d1-cfc7-b023f8f5f860@canonical.com> Date: Tue, 31 Jan 2023 15:48:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices() Content-Language: en-US To: Simon Glass Cc: Tom Rini , u-boot@lists.denx.de, Andre Przywara , Ilias Apalodimas References: <20230128085745.18389-1-heinrich.schuchardt@canonical.com> From: Heinrich Schuchardt In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 1/31/23 15:16, Simon Glass wrote: > Hi, > > On Tue, 31 Jan 2023 at 05:04, Ilias Apalodimas > wrote: >> >> Hi all, >> >> On Mon, Jan 30, 2023 at 01:30:49PM -0500, Tom Rini wrote: >>> On Mon, Jan 30, 2023 at 01:13:55PM -0500, Tom Rini wrote: >>>> On Sat, Jan 28, 2023 at 09:57:45AM +0100, Heinrich Schuchardt wrote: >>>> >>>> I thought we had rejected going down this path since the UEFI spec is >>>> unhelpfully wrong if it insists this? >>> >>> Because, to be clear, stopping hardware watchdogs is not to be done. The >>> one in-tree caller of wdt_stop_all is very questionable. You cannot >>> seriously stop a watchdog until someone else can hopefully resume it as >>> that violates the function of a hardware watchdog. A pure software >>> watchdog is one thing, and a hardware watchdog is another. I feel like >>> the most likely answer here is that someone needs to, still, push back >>> to the UEFI specification to get hardware watchdogs better understood >>> and handled, as it must never be stopped once started and if you cannot >>> reach the next stage in time, that's an engineering issue to resolve. My >>> first guess is that ExitBootServices should service the watchdog one >>> last time to ensure the largest window of time for the OS to take over >>> servicing of the watchdog. >>> >> >> There's two scenarios I can think of >> 1. After U-Boot is done it can disable the hardware watchdog. >> The kernel will go through the EFI-stub -> kernel proper -> watchdog >> gets re-initialized. In that case you are *hoping* that device won't >> hang in the efi-stub or until the wd is up again. >> 2. EFI makes sure the hardware wd gets configured with the highest allowed >> value. The efi-stub doesn't have any driver to refresh the wd, so we >> will again rely on the wd driver coming up and refreshing the timers. >> >> >> None of those is perfect, but I prefer the latter > > How does this work if U-Boot runs grub instead of Linux? Does grub > update the watchdog? > U-Boot will reset the watchdog when the UEFI API is invoked to read the console or to access the network or block devices. Just grep for "efi_timer_check()". Best regards Heinrich