From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from a7-19.smtp-out.eu-west-1.amazonses.com (a7-19.smtp-out.eu-west-1.amazonses.com [54.240.7.19]) by mx.groups.io with SMTP id smtpd.web11.16910.1682681194218218820 for ; Fri, 28 Apr 2023 04:26:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ipxe.org header.s=cphpx6z2rfcgehlykjjh3gknqe3hsoe2 header.b=QNSFbuRL; spf=pass (domain: eu-west-1.amazonses.com, ip: 54.240.7.19, mailfrom: 01020187c79d5eef-190d7d28-3c30-442a-913b-4dae66b71839-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=cphpx6z2rfcgehlykjjh3gknqe3hsoe2; d=ipxe.org; t=1682681192; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=QFuDkpgcgfDrDYGG5X+iXOzC56yWxpZJ+HKKft4o1Sc=; b=QNSFbuRLhLAMHulsWvygNy1FLn+3kGsPGWUPamGb9e9RN789ygwuzltv7wUSwby0 N8X7+peHj/VQN65L8V8n7pmEvRRlzr0IaeO0utvHpO1X3FKGLDqbmGfn1C7mLQhpzvR Ujuw4k8opf8qxMP821/+7ll2QslDnISGLwosP7DurvLs52216Lwd7P4RVLssbtmKXP6 3xToWsqV9MvKvjlmYt/p0/WrFP6vPE6oZhyfM9zhFfX1BgGH3HWZzrFShgRKtZaTIUx z3ziNfUDxcP91DVvtlbEkOeGIp3pSAOtBgF8b86bt545X/xelV5srAtxrJhNLWsQxWd 5REDRiJIWQ== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=shh3fegwg5fppqsuzphvschd53n6ihuv; d=amazonses.com; t=1682681192; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=QFuDkpgcgfDrDYGG5X+iXOzC56yWxpZJ+HKKft4o1Sc=; b=YstF6JjwkG/Lx2LfQP5ORiW0DNbks1/o9nVegOVGFM2IpBgfSTVYtsE1pvKMOEZy 6Ka7+tI5woQiDWJuDJVnDPz4D+HkcpGR4ZKlrS9hreGK/FtUSgLpCxRqSDFJW0U7c3O demgiB1E6Fv3/MwBMB7vSmP2bMxlpEpiAg0m+T9s= Message-ID: <01020187c79d5eef-190d7d28-3c30-442a-913b-4dae66b71839-000000@eu-west-1.amazonses.com> Date: Fri, 28 Apr 2023 11:26:32 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: Gerd Hoffmann , devel@edk2.groups.io Cc: Oliver Steffen , Jiewen Yao , Ard Biesheuvel , Pawel Polawski , Jordan Justen , Laszlo Ersek References: <20230428091019.1506923-1-kraxel@redhat.com> From: "Michael Brown" Subject: Re: [PATCH 1/1] OvmfPkg/NestedInterruptTplLib: replace ASSERT() with a warning logged. In-Reply-To: <20230428091019.1506923-1-kraxel@redhat.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Feedback-ID: 1.eu-west-1.fspj4M/5bzJ9NLRzJP0PaxRwxrpZqiDQJ1IF94CF2TA=:AmazonSES X-SES-Outgoing: 2023.04.28-54.240.7.19 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 28/04/2023 10:10, Gerd Hoffmann wrote: > OVMF can't guarantee that the ASSERT() doesn't happen. Misbehaving > EFI applications can trigger this. So log a warning instead and try > to continue. > > Reproducer: Fetch windows 11 22H2 iso image, boot it in qemu with OVMF. > > Traced to BootServices->Stall() being called with IPL=TPL_HIGH_LEVEL > and Interrupts /enabled/ while windows is booting. Do we know how the system ended up in a state of being at TPL_HIGH_LEVEL with interrupts enabled? This ought not to be possible: the code in EDK2 will (as far as I can tell) always maintain the invariant that interrupts are disabled while at TPL_HIGH_LEVEL. > --- a/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c > +++ b/OvmfPkg/Library/NestedInterruptTplLib/Tpl.c > @@ -39,7 +39,15 @@ NestedInterruptRaiseTPL ( > // > ASSERT (GetInterruptState () == FALSE); > InterruptedTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL); > - ASSERT (InterruptedTPL < TPL_HIGH_LEVEL); > + if (InterruptedTPL >= TPL_HIGH_LEVEL) { > + DEBUG (( > + DEBUG_WARN, > + "%a: Called at IPL %d, trying to fixup and continue...\n", > + __func__, > + InterruptedTPL > + )); > + InterruptedTPL = TPL_HIGH_LEVEL - 1; > + } This workaround looks wrong to me: it will cause the subsequent call to NestedInterruptRestoreTPL() to drop the TPL back down to TPL_HIGH_LEVEL-1, which is lower than it would have been when the interrupt occurred. The completed hardware interrupt would then result in an overall change of TPL, which cannot be correct. Thanks, Michael