From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id B8D797803E5 for ; Tue, 16 Jan 2024 15:37:12 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=O5funTO/mzUPdRVtkj34GGxMpHaD51sRTPBqnvoqN5k=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1705419431; v=1; b=UjmdS7OLl/LM3i/2a01moXf2oy+tQ17b664OMt8TkU1d0OogYtfTmcwa9QmtHmLwVGEtMM0Z MpBoWzT8IraO0ARLrahakM/YwIRCDM8d6gZv4quSqmwbqwRfgePYHf+8z7IuPShJCZ4x7BF4lnn 8H5N6Sdfu95MlS8v7VfZh4qM= X-Received: by 127.0.0.2 with SMTP id 5saKYY7687511xhOmhBd5Nv4; Tue, 16 Jan 2024 07:37:11 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.18278.1705419430408926567 for ; Tue, 16 Jan 2024 07:37:10 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-101-jStwLtojN9GHMWLM69n-NA-1; Tue, 16 Jan 2024 10:37:05 -0500 X-MC-Unique: jStwLtojN9GHMWLM69n-NA-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2A98D86F12B; Tue, 16 Jan 2024 15:37:05 +0000 (UTC) X-Received: from [10.39.193.181] (unknown [10.39.193.181]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C55EBC15E6C; Tue, 16 Jan 2024 15:37:03 +0000 (UTC) Message-ID: Date: Tue, 16 Jan 2024 16:37:02 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver To: devel@edk2.groups.io, mcb30@ipxe.org, kraxel@redhat.com Cc: Pedro Falcato , ray.ni@intel.com, Michael D Kinney , Nate DeSimone , Rahul Kumar References: <20240115080325.147-1-ray.ni@intel.com> <20240115080325.147-2-ray.ni@intel.com> <0102018d11ac8fe8-1ce1e102-af57-426f-bafc-7297bec4799a-000000@eu-west-1.amazonses.com> <0102018d12d8bd9f-d209332f-f501-498e-b43c-3b0cc4f7ef7b-000000@eu-west-1.amazonses.com> From: "Laszlo Ersek" In-Reply-To: <0102018d12d8bd9f-d209332f-f501-498e-b43c-3b0cc4f7ef7b-000000@eu-west-1.amazonses.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: MtCynOPGdJ1AZeyf1l7j04rdx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=UjmdS7OL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 1/16/24 16:16, Michael Brown wrote: > On 16/01/2024 14:34, Laszlo Ersek wrote: >> On 1/16/24 10:48, Michael Brown wrote: >> IOW, my impression is that NestedInterruptTplLib can certainly handle >> all scenarios thrown at it, but where it really matters is in the face >> of an interrupt storm (not just "normal nesting"), and a storm is >> unlikely (or even impossible?) on physical hardware. >> >> ... Oh, scratch that. "Interrupt storm" simply means that interrupts are >> being delivered at a rate higher than the handler routine can service >> them. IOW, the "storm" is not that interrupts are delivered *very >> rapidly* in an absoulte sense. If interrupts are delivered at normal >> frequency, but the handler is too slow to service *even that rate*, then >> that also qualifies as "storm", because the nesting depth will *keep >> growing*. It's not really the growth rate that matters; what matter is >> the *trend*, i.e., the fact that there *is* growth (the stack gets >> deeper and deeper). The stack might not overflow immediately, and if the >> handler speeds up (for whatever reason), the stack might recover, but >> there is nothing to prevent an overflow. >> >> So, in the end, I think you've convinced me. > > :) > >>> I'm happy to send a patch to migrate NestedInterruptTplLib to >>> MdeModulePkg, so that it can be consumed outside of OvmfPkg.  Shall I do >>> this? >> >> Sounds like a valid idea to me. >> >> Could be greatly supported by a test case (to be run on the bare metal) >> installing a slow handler that *eventually* exhausted the stack, when >> not using NestedInterruptTplLib. >> >> (FWIW, IIRC, the UEFI spec warns about this -- it says something like, >> "return from TPL_HIGH as soon as you can, otherwise the system will >> become unstable".) >> >> Sorry for the wall of text, I find this very difficult to reason about. > > I also find it very difficult to reason about, which is why > NestedInterruptRestoreTpl() has 126 lines of comments providing a > semi-formal proof of correctness for a mere 15 statements of C code! > > In particular, I find it difficult to reason about when it would be safe > for a platform to *not* use NestedInterruptTplLib.  It's clearly > empirically difficult to trigger stack underflow via an interrupt > "storm" on physical hardware, but I'm not convinced it's impossible. > > I find it mentally easier to rely on the hard guarantee that > NestedInterruptTplLib provides: that nested interrupts will continue to > be delivered but that the number of interrupt-induced stack frames is > bounded by the (small, finite) number of distinct TPL levels in existence. > > > > While developing NestedInterruptTplLib, I did hack together a test case > for a slow handler that would deliberately induce an interrupt storm, > since I needed this to test that my code was working.  When triggered, > this test would cause the machine to effectively hang due to servicing > an endless storm of timer interrupts.  Before NestedInterruptTplLib, the > stack would soon underflow and would typically cause a reboot (or other > crash).  With NestedInterruptTplLib the machine would continue to > service interrupts indefinitely. > > How might such a test case be included in upstream EDK2?  I'm > peripherally aware of EDK2 test infrastructure such as UEFI SCT, but > I've never interacted with it yet. I'm vaguely aware of a unit test framework inside edk2, but the best I can give you is just this link: https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg#unit-test-framework-package There are some files under the directory "MdeModulePkg/Test" too; git-log on that subdir, and perhaps the MdeModulePkg maintainers, might provide more pointers. The end of the readme linked above says to ask Bret, Mike and Sean, as well. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113910): https://edk2.groups.io/g/devel/message/113910 Mute This Topic: https://groups.io/mt/103734961/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-