From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (NAM11-DM6-obe.outbound.protection.outlook.com [40.107.223.123]) by mx.groups.io with SMTP id smtpd.web12.10722.1602540871415618490 for ; Mon, 12 Oct 2020 15:14:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=aZRNLPK5; spf=pass (domain: microsoft.com, ip: 40.107.223.123, mailfrom: bret.barkelew@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kS+WghJuf+/cDYr50Pi7SU+VyqkUgLD9CM9H+uftBkznD4Gqi/3kDd9B+SpXHj/kLp441afBrn8zGQ5g8fT/trZYmcxmeSDEe9EfjU63Dve6MliR+4u2KGUpcIMsA2EuePya+TAoIrhgHpcs7sMsTIKwX8LEZs5cBPso9jykSPWLP+ihCgR9Zy/xFSWg8jjMGvdc9Ly4kkL+ampqetYfwpxW7nIrda36vOF10/1ZFFgmZt9qet1vpMBcCXU7SJbhdQm/BQgNyYYWJaXQREWJiqnXUznTd3PweZWJ6AtjihGNdFNwRt0TG6RSQidGEJgYfL40DrK2CYH7Zu2oGUuPCA== 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-SenderADCheck; bh=FoYKCLF3kUPwM44sIMS8Ei1aUg8XVFtVQGTy17f21Q0=; b=HoJl65HbgSf1EvVOLXxYnzgib2hG1ddLq2gYnppHbbDAwWPd+YL/yRNc76TyFYGprIeNCfZ2kqvri844cJDmc+EhFgvWeNZbkVvLO6LKuEmgUw5nde9e+q81tIknpLsSDAQX8HoI+eB+CalXRpAUxC73fVccAzqxNlu51dB0ob3ocprFGKLc6kW74RsBBnastWN0K13QWb0psnLIgYgF1Roo61FgAl1ejvEzTgNjvUxB6ct0fnkiE85zQ2bWQ7cLRoAt/pcMMIPipV6BkeMXiZRKPHPT8Pnc6q/qji7PBg12N1A/XCjo/iKrHdQQ+YBK0CPnhgAhrbDV3DzlYZWTQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FoYKCLF3kUPwM44sIMS8Ei1aUg8XVFtVQGTy17f21Q0=; b=aZRNLPK5RiQUxYgLxUhdQCJNhNfGvDOeyF6SYb9Z8yB+uXb1OZUQSX5apBKw1r0+6SLJkmB7cspvmwnYoyDPFY+b9LAP4AO02vCLj6QDgTbaZ2C+Zex/8+8MZP0EDuKsnHrO5xgZ20cUhYitwVBPzB4z2HaJm/4Z/tbHQd7RjnY= Received: from MW4PR21MB1857.namprd21.prod.outlook.com (2603:10b6:303:74::12) by MWHPR2101MB0810.namprd21.prod.outlook.com (2603:10b6:301:78::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.3; Mon, 12 Oct 2020 22:14:29 +0000 Received: from MW4PR21MB1857.namprd21.prod.outlook.com ([fe80::2967:7434:51bb:e234]) by MW4PR21MB1857.namprd21.prod.outlook.com ([fe80::2967:7434:51bb:e234%4]) with mapi id 15.20.3499.003; Mon, 12 Oct 2020 22:14:29 +0000 From: "Bret Barkelew" To: "Kinney, Michael D" , Andrew Fish , edk2-devel-groups-io Subject: Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering Thread-Topic: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering Thread-Index: AQHWnMXk1DxrbQsLX0+f/XLnepxYJqmMVlmPgAfeE4CAAFojGA== Date: Mon, 12 Oct 2020 22:14:29 +0000 Message-ID: References: <38FD7E16-93BD-45D1-985A-702A9776D3D3@apple.com>, , In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-07T16:36:03.7772527Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.212.128.184] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 805ec034-6b8a-4b13-28b6-08d86efc3062 x-ms-traffictypediagnostic: MWHPR2101MB0810: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: amICyKs5VKgJ9vl9IPC+dj5p52dpZXbs1MGz0tlz9BA/uV1+F1BOLLS0uqtYGAcBOZyb3tT1eQJkw8HJ42PPLvNFCA+Sy+x8+lmnzsepEqLvTI/bzsNXiulnGwyyasWvqnZ8tykMJ8yuXnge/bCpsOnOMcmPFJSma0dzKc1dr6e78ETxS0CCTCM6759G2Fb9DDTxo2wgui89yHWyQuoFiMyre1WtY0JarczdpxTbydNKd56rfJpGQCjFFITXprjMsJW789Mu0o6Mj69k+MVSFUYNUEHF4dybILBa6Fnl56hKuInMwN9rR/4uboqty2BgBJXt/foX1chVz7jMSFBgPrWde/qK3M5oQF4DZP8R6YQKLwZ7g7dFtcSQcknTYmPYaKHjxWC3fpHBpVHhwE95Fw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR21MB1857.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(136003)(39860400002)(396003)(366004)(376002)(346002)(76116006)(66556008)(66946007)(66476007)(66616009)(64756008)(66446008)(33656002)(71200400001)(316002)(55016002)(8936002)(82950400001)(8676002)(82960400001)(110136005)(52536014)(86362001)(5660300002)(99936003)(966005)(186003)(26005)(7696005)(10290500003)(83380400001)(8990500004)(2906002)(166002)(478600001)(53546011)(9686003)(6506007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: ojPAZCzoUiy1HtNBpO19UZMIEZ+o22cO+SWPBBTwgJl5FcXDwBpacnLNScoQPPXGZuIP+aXjpQb9r1vpThTku1A4huNeh87Ckf7tXjiL/+6NUhx+ggiwNw86Ppln4EDO7RlEsX2a/NdFWGLilH3y9RnbQkk0sVc5rgUx9+MIkkw/KoHTFJ/bLJt9zJOak0nVXiq5xzvyxMXXUXiuIw1HHth98IMdxiVSSTt4CLKBW96Iqw9LIdlYRw1Hw6suX2OfcEdcusYWD4YJyqmQNIiw0AziAS/qb/tBd7WHpPkYxnw7WVVr9Z17om809D9WsbgnRMcQq1D/LDl7gChefKXXGd+L3Tnh+VK+WNq7/pHHVIPgKvTPpB/oWPJq7ZwEFf9ZJoSEPO+cD0fRE3M5Ws6GZqyRMB7TuidMxCPwnSVC9KE97jQRB5v9aXN+U5XcYZSq4QHSQd05cl0ikpd6bTPe7qV4F6HglYIcxJIWnhQOuSN5TFIeHVQ9SWH0Gaqb5gNVZe8OP3y4WLcOSa9k7X0NsAkIUdcZM3flhqoe9/AZwJZtpYgKXbI2g8yP/L8t1BW9X0yZCYVTg8NiSOLnqYGWcVLpF20aBgWEy7iBXh6NUsNLBA/YoA4PkeSg9PpXCCUd6H8/Ml3uWBTvi2d3ftPLMg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR21MB1857.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 805ec034-6b8a-4b13-28b6-08d86efc3062 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 22:14:29.3268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wKaCsylbfRHkYA/c/wmbuoQyxeZlb7v2SSLTWP53aZAMYPKbA/wnM4HdyaHecjWGRN8rzn8KrJ1cmrR+tCRbOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR2101MB0810 X-Groupsio-MsgNum: 66138 Content-Language: en-US Content-Type: multipart/related; boundary="_004_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_"; type="multipart/alternative" --_004_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_ Content-Type: multipart/alternative; boundary="_000_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_" --_000_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Like I said, I=92m also happy to go with the lesser solution of replacing t= he hack that was already in the code. The last person didn=92t care to solv= e this problem, and I=92m good to not solve it, too. I mean, I think it=92s= turtles all the way down no matter what. It was actually the ASSERT in the code that highlighted this problem to be= ing with, so I would say that it=92s doing its job. It=92s incumbent upon t= he code author to determine what resource they=92re trying to access and wh= ether they=92ve accessed it successfully, and I agree that it seems like an= appropriate use of ASSERTs so long as it=92s backed up with some OTHER app= ropriate action (even if that action is ignoring it). - Bret From: Kinney, Michael D Sent: Monday, October 12, 2020 9:44 AM To: Bret Barkelew; Andrew Fish; edk2-devel-groups-io; Kinney= , Michael D Subject: [EXTERNAL] RE: [edk2-devel] VariablePolicy: Final Changes Thread = 1 - TPL Ordering Bret, How to platform creators know for the complete set of drivers if there is = anything then need to worry about and why and what they need to address the= concern? This is about order that events are signaled for a given event t= rigger. When a platform adds more driver that may use the same event trigg= ers, how do they know if there is a potential for a race condition or not? = If event notification functions are design to be independent of signaling = order, then there is no issue. As soon as there are requirements for event= notification functions to be executed in a specific order at a specific ev= ent trigger, we have to make sure the platform creator knows and preferably= , the FW can tell them if they got it wrong. Can your data/device manipulators and data/device protectors use case gene= rate an ASSERT() if they are signaled in the wrong order? Mike From: Bret Barkelew Sent: Wednesday, October 7, 2020 9:39 AM To: Kinney, Michael D ; Andrew Fish ; edk2-devel-groups-io Subject: RE: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ord= ering Agreed with your concern, Mike. This mechanism (and we can document it as = such) should NOT be used to accomplish an explicit ordering (a la the =93ap= riori list=94). It=92s just to provide a little separation for two patterns= that we=92ve seen time and again in our code: data/device manipulators and= data/device protectors. It does not eliminate the necessity for platform c= reators to understand things like driver ordering if they have one driver t= hat requires a protocol be installed or a bus connected. - Bret From: Kinney, Michael D Sent: Wednesday, October 7, 2020 9:21 AM To: Andrew Fish; edk2-devel-groups-io; Kinney, Michael D Cc: Bret Barkelew Subject: [EXTERNAL] RE: [edk2-devel] VariablePolicy: Final Changes Thread = 1 - TPL Ordering Hi Andrew, I agree DXE drivers could use a PCD to make it configurable and prevent co= llisions with UEFI defined TPL levels. Bret=92s suggestion of adding a DXE scoped services to create events using= non-UEFI defined TPL levels could be used with these TPL levels from PCDs.= Would also allow DXE drivers to use TPL levels associated with the firmwa= re interrupts in the range 17..30. Perhaps extensions to the DXE Services = Table? Still does not address my concern that many DXE drivers using these extra = TPL levels may run into race conditions if more than one DXE driver selects= the same TPL level. Platform integrators will need to understand the rela= tive priorities of all DXE drivers that use extra TPL levels so they can as= sign values that both avoid collisions with future UEFI specs and prevent r= ace conditions among DXE drivers. Mike From: Andrew Fish > Sent: Tuesday, October 6, 2020 7:18 PM To: edk2-devel-groups-io >; Kinney, Michael D > Cc: bret.barkelew@microsoft.com Subject: Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ord= ering Mike, When I=92ve done things like this in the past I think of making them confi= gurable like via a PCD. In terms of the #defines I think it makes more sense to just do math on th= e spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc. I=92ve= got an lldb type formatter for TPL and it prints out [+ ] as I think this is the clearest way to do it. Thanks, Andrew Fish On Oct 6, 2020, at 6:54 PM, Michael D Kinney > wrote: Bret, It is likely best to go with the first approach. The discussion on TPL le= vels can continue and you could adopt it in the future if a general solutio= n is identified. TPL 17..30 are reserved by the UEFI Spec for firmware interrupts. So TPL_= NOTIFY_HIGH as defined would not be allowed. I agree that the use of TPL values other than those defined by the UEFI Sp= ec can potentially be used by DXE. However, that DXE usage must be flexibl= e enough to handle a future extension to the UEFI Spec for new TPL levels w= ithout a collision. Instead of defining specific TPL values, you could add a DXE scoped servic= e to allocate the use of a new TPL level that is not being used by UEFI or = other DXE drivers. I will point out that these approaches (defining new TP= L levels or allocating unused TPL levels) just moves the same problem. You= can solve it for the first driver that needs something special. As soon a= s there is more than one driver that need something special at the same TPL= level, the potential for a race condition for ordering will show up again.= So I do not consider adding TPL levels to be a good general solution to t= his problem. Best regards, Mike From: devel@edk2.groups.io > On Behalf Of Bret Barkelew via groups.io<= https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fgroups.i= o%2F&data=3D04%7C01%7CBret.Barkelew%40microsoft.com%7C3630fdf48d3349fedde40= 8d86ece23e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637381178939940223= %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW= wiLCJXVCI6Mn0%3D%7C1000&sdata=3DB%2FSkE6r5bdZUiS4DvdcIiYEV4sATOssRs1CyDKJeL= yQ%3D&reserved=3D0> Sent: Tuesday, October 6, 2020 5:24 PM To: devel@edk2.groups.io Subject: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Orderin= g As many will be aware, I=92m in the final stages of having Variable Policy= ready for commit. However, after moving the =93Lock=94 event back to EndOf= Dxe, this exposed a race condition in variable services. A quick synopsis of the problem: * Previously, MorLock abused a privileged position by being tightly co= upled to Variable Services, and its lock callback was called directly so th= at it could be strongly ordered with the internal property lock that disabl= es future RequestToLock calls. * VariablePolicy attempted to decouple this (without realizing it was = a problem) and go through formalized interfaces that could ultimately be br= oken out of Variable Services altogether. * However, doing so triggered the race condition, causing an ASSERT wh= en MorLock attempted to lock its variables. * I current have a reimplementation of the strong ordering workaround = that can be previewed at the link below. I have tested that it works the sa= me as the OLD system. * Take a stab at solving the lock ordering problem =B7 corthon/edk2= @e7d0164 (github.com) However, replacing one bad design with another is not what this community = is about (when we can help it), so we=92d like to take a moment to revisit = a conversation that has come up before: expanding the number of supported T= PL levels. Now, I know that the current TPL levels are defined in the UEFI spec and w= e don=92t want to have to change those, but there=92s no reason that we can= come up with not to add some more granularity in the PI spec, dedicated to= platform and implementation ordering (the UEFI spec events will have to re= main on UEFI spec TPLs). Basically there would be a set of DXE Services tha= t allow WaitForEvent, CheckEvent, Event registration at TPLs other than not= ify/callback. The UEFI system table versions of the functions would still = have this restriction but code built with the platform could use the DXE Se= rvices. Right now, any attempt to use a non-UEFI TPL will ASSERT, so we can= keep that in place on the SystemTable interface, but allow the platform to= go around it with DXE Services. Similar functionality would have to be pro= vided by the Mmst, but that=92s already platform-specific and can probably = allow it in all cases. We=92re suggesting something like the below: // // Task priority level // #define TPL_APPLICATION 4 #define TPL_CALLBACK_LOW 7 #define TPL_CALLBACK 8 #define TPL_CALLBACK_HIGH 9 #define TPL_NOTIFY_LOW 15 #define TPL_NOTIFY 16 #define TPL_NOTIFY_HIGH 17 #define TPL_HIGH_LEVEL 31 There=92s already a long-in-the-tooth bug tracking a similar issue: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1676 This proposal is simpler than what=92s in that bug, and would greatly simp= lify some of our event ordering (and code). Thoughts? If this conversation takes too long, I will publish a set of patches that = just go with the lesser solution posted above, but I=92d much rather work t= he problem this way. - Bret --_000_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Like I said, I=92m also happy to go with the lesser= solution of replacing the hack that was already in the code. The last pers= on didn=92t care to solve this problem, and I=92m good to not solve it, too= . I mean, I think it=92s turtles all the way down no matter what.

 

It was actually the ASSERT in the code that highlig= hted this problem to being with, so I would say that it=92s doing its job. = It=92s incumbent upon the code author to determine what resource they=92re = trying to access and whether they=92ve accessed it successfully, and I agree that it seems like an appropriate use of ASS= ERTs so long as it=92s backed up with some OTHER appropriate action (even i= f that action is ignoring it).

 

- Bret

 

From: Kinney, Michael D
Sent: Monday, October 12, 2020 9:44 AM
To: Bret Barkelew; Andrew Fish; edk2-devel-groups= -io; Kinney, Michael D
Subject: [EXTERNAL] RE: [edk2-devel] VariablePolicy: Final Changes = Thread 1 - TPL Ordering

 

Bret,

 

How to platform creators know for the complete set = of drivers if there is anything then need to worry about and why and what t= hey need to address the concern?  This is about order that events are = signaled for a given event trigger.  When a platform adds more driver that may use the same event triggers, how do = they know if there is a potential for a race condition or not?  If eve= nt notification functions are design to be independent of signaling order, = then there is no issue.  As soon as there are requirements for event notification functions to be executed in a spe= cific order at a specific event trigger, we have to make sure the platform = creator knows and preferably, the FW can tell them if they got it wrong.

 

Can your data/device manipulators and data/device p= rotectors use case generate an ASSERT() if they are signaled in the wrong o= rder?

 

Mike

 

From: Bret Barkelew <Bret.Barkelew@micros= oft.com>
Sent: Wednesday, October 7, 2020 9:39 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Andrew Fi= sh <afish@apple.com>; edk2-devel-groups-io <devel@edk2.groups.io&g= t;
Subject: RE: [edk2-devel] VariablePolicy: Final Changes Thread 1 - = TPL Ordering

 

Agreed with your concern, Mike. This mechanism (and= we can document it as such) should NOT be used to accomplish an explicit o= rdering (a la the =93apriori list=94). It=92s just to provide a little sepa= ration for two patterns that we=92ve seen time and again in our code: data/device manipulators and data/device protector= s. It does not eliminate the necessity for platform creators to understand = things like driver ordering if they have one driver that requires a protoco= l be installed or a bus connected.

 

- Bret

 

 

Hi Andrew,

 

I agree DXE drivers could use a PCD to make it conf= igurable and prevent collisions with UEFI defined TPL levels.

 

Bret=92s suggestion of adding a DXE scoped services= to create events using non-UEFI defined TPL levels could be used with thes= e TPL levels from PCDs.  Would also allow DXE drivers to use TPL level= s associated with the firmware interrupts in the range 17..30.  Perhaps extensions to the DXE Services Table?<= o:p>

 

Still does not address my concern that many DXE dri= vers using these extra TPL levels may run into race conditions if more than= one DXE driver selects the same TPL level.  Platform integrators will= need to understand the relative priorities of all DXE drivers that use extra TPL levels so they can assign values th= at both avoid collisions with future UEFI specs and prevent race conditions= among DXE drivers.

 

Mike

 

From: Andrew Fish <afish@apple.com>
Sent: Tuesday, October 6, 2020 7:18 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: bret.barkelew@mi= crosoft.com
Subject: Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - = TPL Ordering

Mike,

 

When I=92ve done things like this in the past I thi= nk of making them configurable like via a PCD. 

 

In terms of the #defines I think it makes more sens= e to just do math on the spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc.  I=92ve= got an lldb type formatter for TPL and it prints out <UEFI Spec TPL> [+ <extra>] as I think this is the clear= est way to do it. 

 

Thanks,=

 

Andrew Fish

 

On Oct 6, 2020, at 6:54= PM, Michael D Kinney <mic= hael.d.kinney@intel.com> wrote:

 

Bret,

 

It is likely best to go= with the first approach.  = The discussion on TPL levels can continue and you could adopt it in = the future if a general solution is identified.

 

TPL 17..30 are reserved= by the UEFI Spec for firmware interrupts.  So TPL_NOTIFY_HIGH as defined would not be allowed.=

 

I agree that the use of= TPL values other than those defined by the UEFI Spec can potentially be us= ed by DXE.  However,= that DXE usage must be flexible enough to handle a future extension to the UEFI Spec for new TPL levels without a collisio= n.

 

Instead of defining spe= cific TPL values, you could add a DXE scoped service to allocate the use of= a new TPL level that is not being used by UEFI or other DXE drivers. =  I will point out that these approaches (defining new TPL levels or allocati= ng unused TPL levels) just moves the same problem.  You can solve it for the first driver that = needs something special.  <= /span>As soon as there is more than one driver that need something special at the = same TPL level, the potential for a race condition for ordering will show u= p again.  So I do no= t consider adding TPL levels to be a good general solution to this problem.

 

Best regards,

 

Mike

 

From: devel@edk2.groups.io <devel@edk2.groups.io&g= t; On Behalf Of Bret Bark= elew via groups.io
Sent: Tuesday, Oc= tober 6, 2020 5:24 PM
To: devel@edk2.groups.= io
Subject: [edk2-de= vel] VariablePolicy: Final Changes Thread 1 - TPL Ordering

 

As many will be aware, = I=92m in the final stages of having Variable Policy ready for commit. Howev= er, after moving the =93Lock=94 event back to EndOfDxe, this exposed a race= condition in variable services.

 

A quick synopsis of the= problem:

  • Previously, MorLock abused a privileged position by being tightly coupled = to Variable Services, and its lock callback was called directly so that it = could be strongly ordered with the internal property lock that disables fut= ure RequestToLock calls.
  • VariablePolicy attempted to decouple this (without realizing it was a prob= lem) and go through formalized interfaces that could ultimately be broken o= ut of Variable Services altogether.
  • However, doing so triggered the race condition, causing an ASSERT when Mor= Lock attempted to lock its variables.
  • I current have a reimplementation of the strong ordering workaround that c= an be previewed at the link below. I have tested that it works the same as = the OLD system.

 

However, replacing one = bad design with another is not what this community is about (when we can he= lp it), so we=92d like to take a moment to revisit a conversation that has = come up before: expanding the number of supported TPL levels.

 

Now, I know that the cu= rrent TPL levels are defined in the UEFI spec and we don=92t want to have t= o change those, but there=92s no reason that we can come up with not to add= some more granularity in the PI spec, dedicated to platform and implementation ordering (the UEFI spec events will have t= o remain on UEFI spec TPLs). Basically there would be a set of DXE Services= that allow WaitForEvent, CheckEvent, Event registration at TPLs other than= notify/callback.  The UEFI system table versions of the functions would still have this restriction but cod= e built with the platform could use the DXE Services. Right now, any attemp= t to use a non-UEFI TPL will ASSERT, so we can keep that in place on the Sy= stemTable interface, but allow the platform to go around it with DXE Services. Similar functionality would h= ave to be provided by the Mmst, but that=92s already platform-specific and = can probably allow it in all cases.

 

We=92re suggesting some= thing like the below:

 

//

// Task priority level

//

#define TPL_APPLICATION       4=

#define TPL_CALLBACK_LOW      7

#define TPL_CALLBACK       = ;   8

#define TPL_CALLBACK_HIGH     9

#define TPL_NOTIFY_LOW      &nb= sp; 15

#define TPL_NOTIFY       &= nbsp;    16

#define TPL_NOTIFY_HIGH       1= 7

#define TPL_HIGH_LEVEL      &nb= sp; 31

 

There=92s already a lon= g-in-the-tooth bug tracking a similar issue:

 

This proposal is simple= r than what=92s in that bug, and would greatly simplify some of our event o= rdering (and code).

 

Thoughts?

 

If this conversation ta= kes too long, I will publish a set of patches that just go with the lesser = solution posted above, but I=92d much rather work the problem this way.

 

- Bret

 

 

 

--_000_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_-- --_004_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_ Content-Type: image/png; name="3EC3C307D51E4C48BFCC86763C0E0E74.png" Content-Description: 3EC3C307D51E4C48BFCC86763C0E0E74.png Content-Disposition: inline; filename="3EC3C307D51E4C48BFCC86763C0E0E74.png"; size=189; creation-date="Mon, 12 Oct 2020 22:14:28 GMT"; modification-date="Mon, 12 Oct 2020 22:14:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAg8AAAADCAYAAAAUeOzwAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAABSSURBVFhH7daxDYAgGAXht4ibGodwIBVLAlob fmlojKULoBPIAnfJt8Np2az646oh3QAAAE2a4/lMwUYXrf9GYgAAAPijdc/F+dSJiIiIqJn0AvT4 V/WmWpizAAAAAElFTkSuQmCC --_004_MW4PR21MB1857AE47B9A653DE7F59AB49EF070MW4PR21MB1857namp_--