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 C89E5C433F5 for ; Tue, 9 Nov 2021 14:46:56 +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 CA66D61178 for ; Tue, 9 Nov 2021 14:46:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CA66D61178 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl 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 134DE83942; Tue, 9 Nov 2021 15:46:54 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id BFBB983618; Tue, 9 Nov 2021 15:46:52 +0100 (CET) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (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 1078783950 for ; Tue, 9 Nov 2021 15:46:45 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id cd3a707e; Tue, 9 Nov 2021 15:46:43 +0100 (CET) Date: Tue, 9 Nov 2021 15:46:43 +0100 (CET) From: Mark Kettenis To: Michael Walle Cc: heinrich.schuchardt@canonical.com, u-boot@lists.denx.de, agraf@csgraf.de, andre.przywara@arm.com, xypron.glpk@gmx.de, michael@walle.cc In-Reply-To: <20211109142017.2834294-1-michael@walle.cc> (message from Michael Walle on Tue, 9 Nov 2021 15:20:17 +0100) Subject: Re: [PATCH 1/1] efi_loader: stop watchdogs in ExitBootServices() References: <20211109101901.24015-2-heinrich.schuchardt@canonical.com> <20211109142017.2834294-1-michael@walle.cc> Message-ID: 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 > From: Michael Walle > Date: Tue, 9 Nov 2021 15:20:17 +0100 > > > The UEFI specification requires for ExitBootServices() that "the boot > > services watchdog timer is disabled". We already disable the software > > watchdog. We should additionally disable the hardware watchdogs. > > What about watchdogs that cannot be stopped? IIRC the IMX SoCs are > like that. You have to hope that your OS takes control of the watchdog quickly enough for the machine not to reset in between. Strictly speaking such a platform can not be fully compliant with the UEFI standard. In practice this doesn't really matter as the OS has to do this quickly enough if you're using a non-UEFI bootpath anyway. Maybe somebody who cares enough can get the UEFI standard amended to handle this scenario. Maybe an interface can be added to the standard to provide more control over the watchdog such that the timeout can be set to a larger value before ExitBootServices() gets called. And add a way to keep the watchdog enabled on SoCs where it can be disabled. Last time this issue came up, someone pointed out that a watchdog that can be turned off isn't a proper watchdog. And indeed, turning the watchdog off when ExitBootServices() gets called means there is a time window where the watchdog isn't running and where the OS could hang forever. Cheers, Mark