From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.73211.1671805569475620973 for ; Fri, 23 Dec 2022 06:26:09 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sTuod1V6; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 02F12B820E2 for ; Fri, 23 Dec 2022 14:26:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA63FC433F1 for ; Fri, 23 Dec 2022 14:26:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671805565; bh=laRJxwEM4taw64+/qfndEuRJuBCOc5mf2H1KR+D8F+8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=sTuod1V646UIMzRMvCeER6FxMdtdJCKBFr+S5XKfOPg10wkOz6RKwVrdy7iw4nvlK zcqsh+1LnDKyd6TBgPb8tpaNcMyJwO63AaqT8Mv4kejQhGMn2C4JplyEs4mayv29eC H1hhy2DM/AyXPdwHNPMkYOLha6z/hn9uW8HI35Lulc8IlqJ/0axaAb8XhbbiwGdV6o lWg/8dvYDGY01zRzRwToObApEEtvhTff8RihiBNaaV//9Y4nHf5jsbZQxFJu4Q/ANS yLTjsLrEDOK8yO71MCsFSp4YQXBVtKcAMzKL9xG7T3/TehBWMu3hoDO+q+fqUo8je/ dexwAX25P4SyQ== Received: by mail-lj1-f173.google.com with SMTP id f20so5182107lja.4 for ; Fri, 23 Dec 2022 06:26:05 -0800 (PST) X-Gm-Message-State: AFqh2kqSiC+dDjliXlAuR8eKnpsopno+st6HMyTlA2HK/Cgu3uwZBVYw 3zSAxP0B0itwJq5NrmvKVfJqNPrtqSIYQTKcP3Y= X-Google-Smtp-Source: AMrXdXvDLjiLTpJlT1rlOxzuTF55ygv1oVVXaRab0zOHFp7o56jD20OzPEZNFl5B3ENUD/pbrrVH5OgwqJROMgbrl7g= X-Received: by 2002:a2e:87c9:0:b0:26d:d603:8df2 with SMTP id v9-20020a2e87c9000000b0026dd6038df2mr461047ljj.189.1671805563623; Fri, 23 Dec 2022 06:26:03 -0800 (PST) MIME-Version: 1.0 References: <01020184f66682f9-7696e0c5-f2f6-43e0-962f-38f1d5af4859-000000@eu-west-1.amazonses.com> <20221209150227.wns5mhtcfismxtgd@sirius.home.kraxel.org> <01020185300e504c-6565abf9-f6d1-41ae-975b-4c59e33c2f2e-000000@eu-west-1.amazonses.com> <407d54f4-537d-375a-224c-184fb5e2dff1@redhat.com> In-Reply-To: <407d54f4-537d-375a-224c-184fb5e2dff1@redhat.com> From: "Ard Biesheuvel" Date: Fri, 23 Dec 2022 15:25:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 2/3] OvmfPkg: Add library to handle TPL from within nested interrupt handlers To: devel@edk2.groups.io, lersek@redhat.com Cc: Michael Brown , kraxel@redhat.com, Paolo Bonzini Content-Type: text/plain; charset="UTF-8" On Wed, 21 Dec 2022 at 09:07, Laszlo Ersek wrote: > > On 12/20/22 16:02, Michael Brown wrote: > > On 09/12/2022 15:22, Michael Brown wrote: > >> On 09/12/2022 15:02, Gerd Hoffmann wrote: > >>>> Add the Nested Interrupt TPL Library (NestedInterruptTplLib) to > >>>> provide helper functions that can be used by nested interrupt > >>>> handlers in place of RaiseTPL()/RestoreTPL(). > >>> > >>> > >> > >>> The idea looks sane to me and I couldn't spot any logic errors in > >>> this. > >> > >> Great! :) > > > > Ping. Is there anything else that needs to be done before this gets > > merged? It would be good to have the regression bug fixed. > > > > Thanks, > > > > Michael > > > > series > Acked-by: Laszlo Ersek > > Ard, can you please help merge this? > Sure. For the ARM case, it seems the situation is slightly different, given that we reprogram the timer for the next interrupt in TimerInterruptHandler (), so I don't think we can accumulate pending interrupts in the same way as x86. So i'm fine with making this fix specific to OVMF/x86. Queued as #3829