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 A26F67803CD for ; Fri, 19 Jan 2024 23:44:10 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=iGsiEnNx2SBPPjIK9iRo6nTZE6OxgCPGgJnM2e/Wig0=; c=relaxed/simple; d=groups.io; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References:In-Reply-To:Accept-Language:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type; s=20140610; t=1705707849; v=1; b=SsQ7J3Ee1ti3nmbhgV6lqJpeQFOGbJuaCwZ4HHN2rmRvx/dJA6DrozejNiCJMa+JuMmGAo2B d4hCNmxWQxGcN8ouZuTPSFUDYPf7kvnt1m2FWLUJeXsaU7RJNPINMeYhs45W8/tAEL1mN9PvBzP FhCf/v8QV0b0cMWcjKr0Fln4= X-Received: by 127.0.0.2 with SMTP id Crd6YY7687511x3l0GjJiTsL; Fri, 19 Jan 2024 15:44:09 -0800 X-Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web10.8414.1705707847925191514 for ; Fri, 19 Jan 2024 15:44:08 -0800 X-IronPort-AV: E=McAfee;i="6600,9927,10957"; a="487023335" X-IronPort-AV: E=Sophos;i="6.05,206,1701158400"; d="scan'208,217";a="487023335" X-Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2024 15:44:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10957"; a="958243155" X-IronPort-AV: E=Sophos;i="6.05,206,1701158400"; d="scan'208,217";a="958243155" X-Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga005.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 19 Jan 2024 15:44:06 -0800 X-Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 19 Jan 2024 15:44:05 -0800 X-Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 19 Jan 2024 15:44:05 -0800 X-Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Fri, 19 Jan 2024 15:44:05 -0800 X-Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 19 Jan 2024 15:44:05 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PqT/jnmV8sNnOdOym3RWhgIzzKjkw7mtxS3PNzzaNY+QHcra4F77KBMrszu+lcK+/gV8nUalP5lqYtaJ3mcP3E2P/+t+rhUsqyBAmF2FfCL2QSVShCOjxExBYqzL8yxxLkhv43iWXecD/RdQb+1xnESJGzeuA8U4t2LM0xDwqQTEYfTDSIDglv4zD7OeV+wyvfsfOgXLzyhbs7yWozq1nDsoN3ITw5yxITIgHajmHvHJpQGuip9JEmv07PNSHiWwA1T6V3XK5VZRQEg0wrG5YjWU4kGXiF8mWr7kmM4sw43PVVX2HmGFRQ+3S+CG3RRR8de9hYii0HnG06zyVga0jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ESRElB8A1lAO1XCSrD8oETmHFHkIR25F0aHBSUi2koE=; b=f29oRLA1R2ShPP7xvffRmbRysn5AxO4XG2ss6tmmv26ST8Gx5KhggOKDGH88lnaDretN1X0s/ulzo2qx0qOtQ7me82FM/5WipMqrAFfSKQCKT8KRETsNP8HuuvRLz1K37ki3KcAFFxMLyaIo0GDZ9HMJXN716PWGdTa1IEEWR30JtV9MQaMQfYsrZ0HfghnR28bwzL3O7u9UfSkVinlvAxWJ6Ob4xz6u6aAs/X7IxyW6vcG7I3rbuIm6ZhQmBTBIFtPe+7ZACJJ4CNm3FsC2E46hF7XxeRxQS5nJJQjZUJXa+XyvRRgsoajMuKx/4p+rC9p+nD+b/BuqE2R8PCUlmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com (2603:10b6:208:470::14) by DS0PR11MB8231.namprd11.prod.outlook.com (2603:10b6:8:15c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7202.24; Fri, 19 Jan 2024 23:44:01 +0000 X-Received: from MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::3fea:ca2b:2ef7:e3d4]) by MN6PR11MB8244.namprd11.prod.outlook.com ([fe80::3fea:ca2b:2ef7:e3d4%4]) with mapi id 15.20.7202.024; Fri, 19 Jan 2024 23:44:01 +0000 From: "Ni, Ray" To: Michael Brown , "devel@edk2.groups.io" , Laszlo Ersek , "kraxel@redhat.com" CC: Pedro Falcato , "Kinney, Michael D" , "Desimone, Nathaniel L" , "Kumar, Rahul R" , "Liu, Zhiguang" Subject: Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver Thread-Topic: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplicate OvmfPkg/LocalApicTimerDxe driver Thread-Index: AQHaSGFHyevSvtTsF0K3gPtn4XXPkrDcgWkAgAAL4gCAAAWlAIAAs3KAgACN2YCAAFpPloADPmOAgABhz+o= Date: Fri, 19 Jan 2024 23:44:01 +0000 Message-ID: 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> <0102018d17080a28-370d97eb-b73c-4811-a9ea-05cfb459ba37-000000@eu-west-1.amazonses.com> <0102018d22d0f904-3aa0bdff-abe9-4c74-8316-0dc17122f372-000000@eu-west-1.amazonses.com> In-Reply-To: <0102018d22d0f904-3aa0bdff-abe9-4c74-8316-0dc17122f372-000000@eu-west-1.amazonses.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN6PR11MB8244:EE_|DS0PR11MB8231:EE_ x-ms-office365-filtering-correlation-id: b3c76df7-59cf-4483-1e04-08dc194883ac x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: I7ck5S0hS0NyVOI5m3SEQzeUCWbT9C5yMXA8/CMAOUVKgoB9bO/obAsbjDxRyLkCzfoEGdNLDn/B9F6r9E+ai7bA3vYjrNym/XAnUYj6siGeDQZ86NY3ppyBj0nM8Aap4M4OJ8FYcwJ8IuvIfH6r1WC45l3dyjQJyGznrAmXKsZX6gh4QnZEuvoktWbiJYvdTl0nUVnBFstCtGz4vAP+JjtJAKk6dx5cg6mCxZ7j+uvJ9hA6CkNEXIfA4bZ2hUJSogQPM553v0BP22jj59jCFW2ozfxmzJOkozkgCF8s/2KNoGjXK+1ObN5B8uXS3QHA8M1IjZe4gzFFFsYY7sfQxx/aS4YNuyqGYbE8smIbmlNVKDekmEJe9+QKwox24tRVAtXwSurSfVfxV8ZL57/yEP4IivujQMVKbJEpPNUue3XYmdNSAP+8RBlyJmH5ASDw4stVbwKiLmEtsIF0l1laRX6ybW55aIFkocCBqVoTDhEPKaKlOF2tHJgxi2f31mIFogQh0l5UJMNiUJxl97Y9/Uv66w4Nd44WxAGPoXnAyY27VwPjK801MDaSxEG3wv1BQPJ6AcSrbSyozXQNpMEf8qGKAzvJPggCidxw2NLqJnFH3nIUh5dJZIaesaqUjVZS x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?C3s217F0jB2VQwmZHNIbYzQDc/giZEcx/DmR2hMP2FcmuYJ8T7t0hgXS?= =?Windows-1252?Q?Vj7KVNQObH6YNsTOV7QygqATgHd3ChZx43UCSO1NGrCFpLGTYLRns8zA?= =?Windows-1252?Q?6qbKnfbTamBAGQY6vX/bQE21JLWMnyZhBqO2yVfbVt7YkQHQuwrwqq1K?= =?Windows-1252?Q?N0EVvIgrcvC1ozXpysinmukbKWrpZo2ztLwChlboJv7bMe1TPxJwaOpy?= =?Windows-1252?Q?Oja0/FT+eCDdZIU67polVGPQxCXyx3srpnBnEyd3R+6SAxW17gx+UPFz?= =?Windows-1252?Q?IzBjgjH4JiifZo2U04xEFA3tA+WklCzNM0WpmRAQeB8pj9tVuTxmUSff?= =?Windows-1252?Q?pyz9cL4onfQbJLH0EmOy3JcSgexwLaf9zly8fa8DzyK1dOqgCOpUiQ7W?= =?Windows-1252?Q?layCEhTQxJ48xcEazyRy5NGdcw3kI9ANXh+9Gv9vUNgk/jM6j2Zz3mTR?= =?Windows-1252?Q?5bh5RzKIt6s8G1+pWlDfvF8rOi7slbCNdoVhDdEB/ixz788Dv6VMDQ57?= =?Windows-1252?Q?P99exipNNZQ/4aHEw9DIueX/AuuYXpsH1i9QUCO+2v/fiSNNGFki5wTC?= =?Windows-1252?Q?KDMlwRPYnUslj9gmzoOEP9hL827RPfcJq+NRyPPcmp/Tcx366hIlNj3D?= =?Windows-1252?Q?iNvPnmODkFNxyVb4aS9VRwwEpnZ4VevHb/7SZjtJ4mYvKoJSbehH4Sb3?= =?Windows-1252?Q?YcNMA9Db/I8W7hePstVAaru9N8BD2NXdf9hPzu66XVdQa9RMkX4fVXNl?= =?Windows-1252?Q?Gfx1s/FvKYyUrnk3+G9elSC2uXyAhFKSDuK2cMh75fgU0GqNn3CJJGOt?= =?Windows-1252?Q?uqCwmJhBsraGf6bbYDlQgYXMuQVjvBann49oxZlWLDJlLE1wvBUgQbzx?= =?Windows-1252?Q?z5XITBTSg6k7fxJHUkjKqQNiZTt/EoWkbkwWolnSAfiMQsPIHwfaF7dv?= =?Windows-1252?Q?Q8UOoggIOVU30LmkRwKdz1yRoWCtXm8gVvHd7X4gTdkjlZkvIAwuFpPl?= =?Windows-1252?Q?sxUf7bV1/hcSiek1hi/xyvW3dp2azymDrg4jihLb6uOvQO5QCMrLetl2?= =?Windows-1252?Q?sbW2yi9VoR9lDSeqmtO3QyTu70vaQC45cx1HE+9zA6jsI+stGTd5PvTz?= =?Windows-1252?Q?/gEr84+pnxKb2yZWiB+DazQzt9mLzjBBwVyeJLml8JkO/QatcXdG0tIW?= =?Windows-1252?Q?rGI6tFSojR45l4NOszGEqf5+iFCNGVwRd5rd5y7jSHOmfT5tAWUBVjdW?= =?Windows-1252?Q?ogZn+TOZm512/S/m3Jv5uixyPNPKJu/9HxWw1YDGMwvA/15pZaYoSTQj?= =?Windows-1252?Q?rIDI5D8UZWLRHEBiHnzEIqOMI549Fpad+2DNOqtM4JI4ycpLrnpf0eEv?= =?Windows-1252?Q?qzNjIK9/1M9tauu/lXQ/bYAta7qygiMZhX+VV0TRtXVqvNUP+2/viiV9?= =?Windows-1252?Q?AkEXwgG3KWWlIAUm6OgMHszgkw7rtbkX8IGFv0X9dmqo61p9a2oP37VM?= =?Windows-1252?Q?EfFzhiNEx2fjso7J58Y0Gdow8bvqahbA5GXaJQCE0E5gLreub0ld6gQY?= =?Windows-1252?Q?NuuOyxMR0b7NqhLU0Pt6gKRAuayKDXQdftk4BFHo1ogxcRZqQgdwnKeL?= =?Windows-1252?Q?T5VXClAZoVthTm9XI0zoQhJhszaueuoNuDwDZaBfQOX6IFhNGUQdqkB/?= =?Windows-1252?Q?Frc2JQZJMzU81KW9PqFwr7Z1NWo+zOcq+DTYSsQs3NVEKkfxsXaRRg?= =?Windows-1252?Q?=3D=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN6PR11MB8244.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3c76df7-59cf-4483-1e04-08dc194883ac X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2024 23:44:01.6704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pE75vVST5zcemLTjh7QgJ5XLNN4RjNr1j5tdy5xybZa1diQqg8dK2KkV2yAoo/DMOaCPtng9K+OK8mV/32jQoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB8231 X-OriginatorOrg: intel.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,ray.ni@intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: oHpBkwXsDhWpCbcLqpX18lXmx7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_MN6PR11MB82446B0C79A9660C56C5CA788C702MN6PR11MB8244namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=SsQ7J3Ee; arc=reject ("signature check failed: fail, {[1] = sig:microsoft.com:reject}"); dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=intel.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 --_000_MN6PR11MB82446B0C79A9660C56C5CA788C702MN6PR11MB8244namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, I still want to see if the RestoreTpl2 that does not enable interrupt is ad= ded as a protocol, and how simple the lib could be. The reason is about maintainability. I can image that one day people would question the Lib implementation if so= me timer event issue appears. If the Lib is easy to understand, the suspici= on could be avoided. And if the correctness of the Lib can be proven by a thorough test, that wi= ll be better. But it seems to me the Lib can only be proven as correct with= careful code review, like some multi-threaded logic. thanks, ray ________________________________ From: Michael Brown Sent: Saturday, January 20, 2024 1:42 AM To: devel@edk2.groups.io ; Ni, Ray = ; Laszlo Ersek ; kraxel@redhat.com Cc: Pedro Falcato ; Kinney, Michael D ; Desimone, Nathaniel L ; K= umar, Rahul R ; Liu, Zhiguang Subject: Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: Duplica= te OvmfPkg/LocalApicTimerDxe driver On 19/01/2024 13:14, Ni, Ray wrote: > So, the interrupt re-entrance we want to avoid is =93env:NOTIFY=94 -> > =93env:NOTIFY=94, or =93env:CALLBACK=94 -> =93env:CALLBACK=94, or =93env:= APPLICATION=94 > -> =93env:APPLICATION=94. Because it=92s endless. > > NestedTplInterruptLib was written to avoid it. Yes, precisely this. > 2. Some questions on NestedInterruptTplLib. > > 1. Can we remove DisableInterruptsOnIret()? That means the inner > interrupt handler would returns to the outer world with interrupt > enabled and TPL=3D=3DHIGH. But I don=92t see any issue with that. Using DisableInterruptsOnIret() allows us to guarantee that absolutely nothing happens between the "DEFERRAL INVOCATION POINT" and "DEFERRAL RETURN POINT" described in the comments in Tpl.c. If we don't use DisableInterruptsOnIret() then we lose this guarantee, and the situation becomes even more complex than it already is. I don't personally feel able to reason through all the possible circumstances that could arise if an interrupt were to occur between "DEFERRAL INVOCATION POINT" and "DEFERRAL RETURN POINT", so I don't feel safe removing the use of DisableInterruptsOnIret(). I have a vague memory that I was still experiencing some kind of crashes before I added DisableInterruptsOnIret(), but I cannot now remember any details, sorry. > 2. If DxeCore can be changed, do you have an easier-to-understand > solution? It really took me 2 days to understand why > NestedInterruptTplLib is written in today=92s way. The ability to change DxeCore doesn't help, unfortunately. If we could change the prototype of RaiseTPL() and RestoreTPL() to include a flag indicating whether or not interrupts should be enabled at the point that RestoreTPL() returns, then that would allow for an easier-to-understand solution. This would require making a breaking change to the UEFI specification, though, so it's not a viable solution. I do appreciate that it's difficult to understand the internals of NestedInterruptTplLib. It's fundamentally having to solve a very difficult problem within the constraints of the UEFI API. I think the solution that NestedInterruptTplLib provides is as simple as it's possible to get, and it does at least have the advantage that all of the complexity is hidden inside the library: the caller gets to just change two lines: - OriginalTPL =3D gBS->RaiseTPL(TPL_HIGH_LEVEL); + OriginalTPL =3D NestedInterruptRaiseTPL(); ... - gBS->RestoreTPL(OriginalTPL); + NestedInterruptRestoreTPL(OriginalTPL, Context, &State); I'll send through a patch to move NestedInterruptTplLib to MdeModulePkg. Thanks, Michael -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114102): https://edk2.groups.io/g/devel/message/114102 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/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --_000_MN6PR11MB82446B0C79A9660C56C5CA788C702MN6PR11MB8244namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Michael,
I still want to see if the RestoreTpl2 that does not enabl= e interrupt is added as a protocol, and how simple the lib could be.
The reason is about maintainability. 
I can image that one day people would question the Lib imp= lementation if some timer event issue appears. If the Lib is easy to = understand, the suspicion could be avoided.
And if the correctness of the Lib can be proven by a= thorough test, that will be better. But it seems to me the Lib can only be= proven as correct with careful code review, like some multi-threaded logic= .



thanks,
ray
From: Michael Brown <mcb30@ipxe.org>
Sent: Saturday, January 20, 2024 1:42 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Ni, Ray <r= ay.ni@intel.com>; Laszlo Ersek <lersek@redhat.com>; kraxel@redhat.= com <kraxel@redhat.com>
Cc: Pedro Falcato <pedro.falcato@gmail.com>; Kinney, Michael D= <michael.d.kinney@intel.com>; Desimone, Nathaniel L <nathaniel.l.= desimone@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>; Liu= , Zhiguang <zhiguang.liu@intel.com>
Subject: Re: [edk2-devel] [PATCH 1/6] UefiCpuPkg/LocalApicTimerDxe: = Duplicate OvmfPkg/LocalApicTimerDxe driver
 
On 19/01/2024 13:14, Ni, Ray wrote:
> So, the interrupt re-entrance we want to avoid is =93env:NOTIFY=94 &nb= sp;->
> =93env:NOTIFY=94, or =93env:CALLBACK=94 -> =93env:CALLBACK=94, or = =93env:APPLICATION=94
> -> =93env:APPLICATION=94. Because it=92s endless.
>
> NestedTplInterruptLib was written to avoid it.

Yes, precisely this.

>  2. Some questions on NestedInterruptTplLib.
>
>  1. Can we remove DisableInterruptsOnIret()? That means the inner=
>     interrupt handler would returns to the outer w= orld with interrupt
>     enabled and TPL=3D=3DHIGH. But I don=92t see a= ny issue with that.
Using DisableInterruptsOnIret() allows us to guarantee that absolutely
nothing happens between the "DEFERRAL INVOCATION POINT" and "= ;DEFERRAL
RETURN POINT" described in the comments in Tpl.c.

If we don't use DisableInterruptsOnIret() then we lose this guarantee,
and the situation becomes even more complex than it already is.

I don't personally feel able to reason through all the possible
circumstances that could arise if an interrupt were to occur between
"DEFERRAL INVOCATION POINT" and "DEFERRAL RETURN POINT"= , so I don't feel
safe removing the use of DisableInterruptsOnIret().

I have a vague memory that I was still experiencing some kind of crashes before I added DisableInterruptsOnIret(), but I cannot now remember any details, sorry.

>  2. If DxeCore can be changed, do you have an easier-to-understan= d
>     solution? It really took me 2 days to understa= nd why
>     NestedInterruptTplLib is written in today=92s = way.

The ability to change DxeCore doesn't help, unfortunately.

If we could change the prototype of RaiseTPL() and RestoreTPL() to
include a flag indicating whether or not interrupts should be enabled at the point that RestoreTPL() returns, then that would allow for an
easier-to-understand solution.

This would require making a breaking change to the UEFI specification,
though, so it's not a viable solution.


I do appreciate that it's difficult to understand the internals of
NestedInterruptTplLib.  It's fundamentally having to solve a very
difficult problem within the constraints of the UEFI API.  I think the=
solution that NestedInterruptTplLib provides is as simple as it's
possible to get, and it does at least have the advantage that all of the complexity is hidden inside the library: the caller gets to just change two lines:

- OriginalTPL =3D gBS->RaiseTPL(TPL_HIGH_LEVEL);
+ OriginalTPL =3D NestedInterruptRaiseTPL();
   ...
- gBS->RestoreTPL(OriginalTPL);
+ NestedInterruptRestoreTPL(OriginalTPL, Context, &State);


I'll send through a patch to move NestedInterruptTplLib to MdeModulePkg.
Thanks,

Michael

_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#114102) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_MN6PR11MB82446B0C79A9660C56C5CA788C702MN6PR11MB8244namp_--