From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (NAM04-SN1-obe.outbound.protection.outlook.com [40.107.70.103]) by mx.groups.io with SMTP id smtpd.web12.10312.1588869954285018612 for ; Thu, 07 May 2020 09:45:54 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@microsoft.com header.s=selector2 header.b=IM674m5b; spf=pass (domain: microsoft.com, ip: 40.107.70.103, mailfrom: bret.barkelew@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A+T1EC9iUtHBMsjTK0coRafv9KGsgl4LN9ncmNa5U0XbcMifN7m/SFelH/IquJ4bgPaQaip48yNd0IuU83DBv2oK1fCrPKpDBs5nQkcdjw8baENVydK4EY0zPZTLKO3qGKhdFMIRxj0oN1k9OsAFXYjxMOhfJHhzyqov6+kK8+wTbNQZlUFeH2gXo+9333sL1N8WGg4mRSEOy75xIaQr5JFwxnYV2rgHlKZgxdGLakJqbkrcMuQ8wW9Yt1ODkM0ufptUpJHP5DMu0UH1DlXIwzRh27oIr/BQcfCx47qjNUOr4eituvi6SvX538d3YO9QovAHq3NNAihEMhTSiSTjtA== 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=Vf4SLLMdUP3Yv0hOowu2nnXB4oXos2VbsMr/TJa+wa0=; b=GdU25wfRAoi192WtlteBSIV2zwjHOtEIwhYbQ6eza2YrlabMRZ54XY9PNR7Hw/GMQj0aSoitnNiecdywMZZFx5Ge+4IMrCBHmBbbzavcBeyZQOKjVeJOWsbC/6TH+D+WEFqpMSlbOUuvz0qpmd0o1L9kanIpNpyUpCzboFd80/v6uPeKPgnmZsaY4cUTHLa7b/DBbd7QXZECGiDAB5W7cG1gHQSmYqXF/hdI0EVWJwueNgq2NGD/WMJvIOMXHUZFaUu5YZSlibezXpBL1nYcxybtk3dFOZLg+nHm+/pjXIj3E57I0RGobrTB4UFebb0U7ReVner2289V/43DzXj+0Q== 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=Vf4SLLMdUP3Yv0hOowu2nnXB4oXos2VbsMr/TJa+wa0=; b=IM674m5bIqjuYZHlzVAUx3ukAR6aQyENyScsBVTtuokaBHluTACQ/l8o04o5juEztKBpDQcdkevRDqvB5MKUlW6+XfCQfGjXF3v3dlioiB71Moz5vqJweeajk75Kqwi7+s5Mduik6/sc729HIGh2BwnMDJDaS4ynsd7ZguKqn8c= Received: from CY4PR21MB0743.namprd21.prod.outlook.com (2603:10b6:903:b2::9) by CY4PR21MB1553.namprd21.prod.outlook.com (2603:10b6:910:94::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.3; Thu, 7 May 2020 16:45:52 +0000 Received: from CY4PR21MB0743.namprd21.prod.outlook.com ([fe80::90d:10d9:c5bc:5318]) by CY4PR21MB0743.namprd21.prod.outlook.com ([fe80::90d:10d9:c5bc:5318%11]) with mapi id 15.20.2979.017; Thu, 7 May 2020 16:45:51 +0000 From: "Bret Barkelew" To: "devel@edk2.groups.io" , "afish@apple.com" , Ard Biesheuvel CC: Daniel Schaefer , "Chang, Abner (HPS SW/FW Technologist)" , Atish Patra , Heinrich Schuchardt , Atish Patra , Alexander Graf , Anup Patel , "leif@nuviainc.com" , Jordan Justen , Laszlo Ersek Subject: Re: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from? Thread-Topic: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF APRIORIs come from? Thread-Index: AQHWJHLVGwVrRz17B0mxrGwH1eB+d6icogEAgAACwQCAAC9zgIAAAJ1c Date: Thu, 7 May 2020 16:45:51 +0000 Message-ID: References: <20200224221949.28826-1-atish.patra@wdc.com> <4de513ea-26fb-c830-2348-c0f57946fd3d@hpe.com> <3cb1d47e-983f-dd93-33d2-5a7896791dde@arm.com> ,<9B467C1E-7EAC-49D9-B646-D91E60FD7539@apple.com> In-Reply-To: <9B467C1E-7EAC-49D9-B646-D91E60FD7539@apple.com> 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-05-07T16:45:04.9299032Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [174.21.83.205] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c8b484dd-414e-4bb1-6c16-08d7f2a61a80 x-ms-traffictypediagnostic: CY4PR21MB1553: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jmZ5pCAUgRE118Ev3HrOucD+ZHpp8Noc5+aQUs+xGSL3zDdSnpZQm7nT945dEte55Ym8/ecbMQ2EcYeyFcJbyy+XZXfsmWeD9H8nPR0aAU0vvE4k16PA16TBOCnaKBbwfUJsNAuU6r1MJ/L99whHjGqJE29Vyv5tP5r9I9GaW18YMUNnirDdGdPSsOuuxhia1xzr/utUGSlOd/2fFOqJLD5JeZe5ziv97ul/2534ci1+UPDzuW3tS1pjceVcRD1GqoXKDLRuZvPv9zLiugVIKlPgfRzygPfFJQOvZLBR+hdmfA7S0gRej8JV+yB+F2RLQ6dxv46thWDNPbi9+Jq2UuRHfUrqGb2dUB30yPNsrtyEYn02z+VhIiPcNSYTtdk1K79Ct/SC6rUaQTtmgUM9j6a5GRqZ7Ti6qy4OuIZbWqrMxhCJL4rD0ZuVpnsX2VeCUDK/wi+KNExi2KOQBPF4Wkf52HpC+J4qZ+cWbRLWQUE3lgQgdveOBVsNQd+SJ9lzKg/FDIyeOjeUZO6aE83VI4Y5GjDdmoSJLjWOXu2TVC+iHSPtrIbtOHVDDuQLqN0YL5l2ioweUzFpkWYwANlGcvyAgAjvf2h5fLsHvAy2bEA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CY4PR21MB0743.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(33430700001)(33440700001)(478600001)(186003)(26005)(10290500003)(6506007)(7696005)(53546011)(9686003)(166002)(8936002)(55016002)(33656002)(99936003)(82950400001)(8676002)(71200400001)(66616009)(5660300002)(110136005)(54906003)(82960400001)(316002)(86362001)(4326008)(83310400001)(83290400001)(66446008)(52536014)(64756008)(76236002)(66946007)(2906002)(83320400001)(83280400001)(76116006)(7416002)(66556008)(8990500004)(83300400001)(66476007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: w1nywGNGqhqHEItH4KyYr5G2AaLB3x1iYbCrjffAOFucyOVcAnl4n0sipPGGblQuyrAb3ZlmhqpUKkrGntoXbvOaWoX8L8pekj2196LAMp7CXuCkijzMlpwLDeJP6sskYZKElsTsGCrf2x4Ip6gCSg6oBgOEMvKaSTrKrkFl7LHBGpoIWoLxVZ/hmYtEw/F+a3R1+voQXQ5/rT8uyYs2oDDpmf1vks+yy15ZdsPyLtmGVXrAmA182iSdiPYnkw1bhwCZxlUf5F/NnQk3BBJbSK/veTDhcIfu64dIUOczgacjj9COmFrH13e0ei18Ly3iL855rGmenJIPLJc0ljW8Ie3WR4Tz18FiZnlPwWgSD7TXzTjZt1seWy51PHyewEho/tp81rbdQtP3VrYKlbo2s3GAk3IxfkZCaR8ZXl8fcp8lmqqEhnNzirvjEkrCgaTOq0KzHxBasqJjltWytZl7x639KG0ua/PoIB+oH6oP9YDVZ3y1oE47JNc1Kabf0kMGrlvSGn93aKrF32d2FkIHO6OBY2sC35oiE9QPFb3d6D12DjHTd3Bm2NVv0M7YafzTyv95ZvifqSqaXLmT8kcZUCHzZF3o825BKnsnpWeWbqPlayc8B/jadQqe0PntjLMlupinc+WUJk1NpeQSaLiseQqmL+sW84HG3ibZ3I64/j4zfgbx1L5hb7E3qhxrk8NjTbHkUJr2BR1aTknxAhWxMihB9ifcwOGWmZfe7mrxV0w+0TdIQ7DnL9BSMz1GObRc3ISFxcx4PMHni9H/bcUzB3gy4mfoM3TKKHXqbGyT0zA= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8b484dd-414e-4bb1-6c16-08d7f2a61a80 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 16:45:51.8161 (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: 7N4bxwmGtElmreSaZMyGpBBzS56Hcspy5lrVrkT5/Ak8buogHMaRke38On4BcYjm2jzcxagKOcDkt3npSbkEuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB1553 X-Groupsio-MsgNum: 58798 Content-Language: en-US Content-Type: multipart/related; boundary="_004_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_"; type="multipart/alternative" --_004_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_ Content-Type: multipart/alternative; boundary="_000_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_" --_000_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I know I=92ve also seen tests that randomize the driver dispatch order to t= ry to catch these =93implementation-specific=94 edge cases. Perhaps we coul= d instrument something similar with a weekly OVMF CI test? - Bret From: Andrew Fish via groups.io Sent: Thursday, May 7, 2020 9:43 AM To: devel@edk2.groups.io; Ard Biesheuvel Cc: Daniel Schaefer; Chang, Abner (HPS SW/= FW Technologist); Atish Patra; Heinrich Schuchardt; Atish Patra; Alexander Graf; Anup Pa= tel; leif@nuviainc.com= ; Jordan Justen; Laszlo Ersek Subject: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did OVMF A= PRIORIs come from? On May 7, 2020, at 6:53 AM, Ard Biesheuvel > wrote: (+ Laszlo) On 5/7/20 3:43 PM, Daniel Schaefer wrote: On 5/7/20 3:24 PM, Ard Biesheuvel wrote: On 5/7/20 3:18 PM, Daniel Schaefer via groups.io wrote: Hi Ard and others, TLDR; We have APRIORI definitions from other places in EDK2 but there's no= explanation as to why they are there. I'm taking this to the EDK2 list, since it doesn't concern U-Boot. I kept some other people related to UEFI, maybe you're interested ;) On 2/25/20 10:07 AM, Ard Biesheuvel wrote: > What I did notice is the use of APRIORI PEI and APRIORI DXE sections > in your platform descriptions. I recommend you try to avoid that, as > it is a maintenance burden going forward: instead, please use dummy > protocols and NULL library class resolutions if you need to make > generic components depend on platform specific protocols. Also, please > document this - the APRIORI section does not explain *why* you have to > circumvent the ordinary dependency tree based module dispatch. I'm taking a look at this right now. You're absolutely right - we should reduce or document APRIORIs. However, Abner told me that he had only copied most of the FDF from other places in EDK2.This is what we currently have: APRIORI PEI { INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeR= outerPei.inf INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.i= nf INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf } APRIORI DXE { INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf INF Platform/SiFive/U5SeriesPkg/Universal/Dxe/RamFvbServicesRuntimeDxe/= FvbServicesRuntimeDxe.inf } I can remove all of APRIORI PEI and it boots properly. Of the DXEs I can o= nly remove FvbServicesRuntimeDxe, otherwise some DXEs are dispatched in the wr= ong order and boot fails. This means some modules have an undeclared dependency on one of the remain= ing modules. Can you elaborate on how the boot fails in this case? The error is ASSERT [FvbServicesRuntimeDxe] /edk2/MdePkg/Library/DxePcdLib/DxePcdLib.= c(72): !EFI_ERROR (Status) In this line, DxePcdLib tries to consume gPcdProtocolGuid. Therefor if I a= dd the following to FvbServicesRuntimeDxe.inf: [Depex] gEfiPcdProtocolGuid [Protocols] gPcdProtocolGuid ## SOMETIMES_CONSUMES gEfiPcdProtocolGuid ## CONSUMES gGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES gEfiGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES I can boot without error. Looking at MdePkg/Library/DxePcdLib/DxePcdLib.inf I see that the library h= as exactly the same Depex and Protocols specified. Do DXEs have re-specify th= em? If yes, of what use is it to declare them for the library? Documentation o= nly? No this is unexpected. If the PcdLib dependency of FvbServicesRuntimeDxe.i= nf resolves to MdePkg/Library/DxePcdLib/DxePcdLib.inf, it should inherit th= e depex and the protocol dependencies. Could be the dreaded my INF is wrong but it compiles issue. What happens i= s dependencies in the INF are missing but get resolved by the library insta= nces or even worse libraries pulled in by the libraries. So it looks to me = like it is a missing Depex in the driver. Not all instances of the library,= that are valid for the module, imply the dependency. /Volumes/Case/edk2(master)>git grep PcdLib -- *.inf | grep LIBRARY_CLASS MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf:21: LIBRARY_CLASS = =3D PcdLib MdePkg/Library/DxePcdLib/DxePcdLib.inf:35: LIBRARY_CLASS = =3D PcdLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE = UEFI_APPLICATION UEFI_DRIVER MdePkg/Library/PeiPcdLib/PeiPcdLib.inf:32: LIBRARY_CLASS = =3D PcdLib|PEIM PEI_CORE SEC The easiest way to debug these kind of problems is to generate a report fi= le by passing `-y REPORTFILE` to build. For my projects I usually always bu= ild a report file and dump it into the Build results directory. This will s= how what libraries got linked in, and what the actual dependency expression= resolved to. Should I/we try to remove the APRIORI entries from OVMF in a similar way? Let's get to the bottom of this first. Laszlo may remember why exactly tho= se entries are there in the first place, and I suspect it is a different is= sue. It is good to get the history. In general the APRIORI files are used to fo= rce a dispatch order for debugging, like getting status codes or serial out= put quicker. >>From an architectural point of view the dispatch order is only defined as = "if your Depex is TRUE you can be dispatched". So they APRORI file lets you= define the undefined behavior. The implementation happens to walk the FV i= n order and will dispatch and drivers with a Depex of TRUE and keep iterat= ing until all the Depex'es are TRUE or all the drivers dispatch. In the "go= od old days" we would sort the PEIMs in dispatch order so that everything w= ould dispatch on the 1st pass to reduce the number of slow FLASH reads requ= ired to boot. Thanks, Andrew Fish --_000_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I know I=92ve also seen tests that randomize the dr= iver dispatch order to try to catch these =93implementation-specific=94 edg= e cases. Perhaps we could instrument something similar with a weekly OVMF C= I test?

 

- Bret

 

From: Andrew Fish via groups.io Sent: Thursday, May 7, 2020 9:43 AM
To: devel@edk2.groups.io; Ard Biesheuvel
Cc: Daniel Schaefer;= Chang, Abner (HPS SW/FW Technologist); Atish Patra; Heinrich Schuchardt= ; Atish Patra; Alexander Graf; Anup Patel; leif@nuviainc.com= ; Jordan Justen; Laszlo Ersek Subject: [EXTERNAL] Re: [edk2-devel] APRIORI in RISC-V or Where did= OVMF APRIORIs come from?

 

 



On May 7, 2020, at 6:53 AM, Ard Biesheuvel <Ard.Biesheuvel@arm.com> wrote:=

 

(+ Laszlo)

On 5/7/20 3:43 PM, Daniel Schaefer wrote:

On 5/7/20 3:24 PM, Ard Biesheuvel wrote:

On 5/7/20 3:18 PM, Daniel Schaefer via groups.io wrote:

Hi Ard and others,

TLDR; We have APRIORI definitions from other places in EDK2 but there's no= explanation as to why they are there.

I'm taking this to the EDK2 list, since it doesn't concern U-Boot.
I kept some other people related to UEFI, maybe you're interested ;)

On 2/25/20 10:07 AM, Ard Biesheuvel wrote:
 > What I did notice is the use of APRIORI PEI and APRIORI DXE sec= tions
 > in your platform descriptions. I recommend you try to avoid tha= t, as
 > it is a maintenance burden going forward: instead, please use d= ummy
 > protocols and NULL library class resolutions if you need to mak= e
 > generic components depend on platform specific protocols. Also,= please
 > document this - the APRIORI section does not explain *why* you = have to
 > circumvent the ordinary dependency tree based module dispatch.<= br>
I'm taking a look at this right now.
You're absolutely right - we should reduce or document APRIORIs.

However, Abner told me that he had only copied most of the FDF from other<= br> places in EDK2.This is what we currently have:

APRIORI PEI {
   INF MdeModu= lePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf 
   INF MdeModu= lePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
   INF  M= deModulePkg/Universal/PCD/Pei/Pcd.inf
}
APRIORI DXE {
   INF MdeModu= lePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF  M= deModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF Platfor= m/SiFive/U5SeriesPkg/Universal/Dxe/RamFvbServicesRuntimeDxe/FvbServicesRunt= imeDxe.inf 
}

I can remove all of APRIORI PEI and it boots properly. Of the DXEs I can o= nly
remove FvbServicesRuntimeDxe, otherwise some DXEs are dispatched in the wr= ong
order and boot fails.


This means some modules have an undeclared dependency on one of the remain= ing modules. Can you elaborate on how the boot fails in this case?

The error is
  ASSERT [FvbServic= esRuntimeDxe] /edk2/MdePkg/Library/DxePcdLib/DxePcdLib.c(72): !EFI_ERROR (S= tatus)
In this line, DxePcdLib tries to consume gPcdProtocolGuid. Therefor if I a= dd
the following to FvbServicesRuntimeDxe.inf:
[Depex]
  gEfiPcdProtocolGu= id
[Protocols]
  gPcdProtocolGuid&= nbsp;           &nbs= p;            &= nbsp;    ## SOMETIMES_CONSUMES
  gEfiPcdProtocolGu= id            &= nbsp;           &nbs= p;  ## CONSUMES
  gGetPcdInfoProtoc= olGuid           &nb= sp;           ## SOMETIME= S_CONSUMES
  gEfiGetPcdInfoPro= tocolGuid           =          ## SOMETIMES_CONSUMES
I can boot without error.
Looking at MdePkg/Library/DxePcdLib/DxePcdLib.inf I see that the library h= as
exactly the same Depex and Protocols specified. Do DXEs have re-specify th= em?
If yes, of what use is it to declare them for the library? Documentation o= nly?


No this is unexpected. If the PcdLib dependency of FvbServicesRuntimeDxe.i= nf resolves to MdePkg/Library/DxePcdLib/DxePcdLib.inf, it should inherit th= e depex and the protocol dependencies.

 

Could be the dreaded my INF is wrong but it compile= s issue. What happens is dependencies in the INF are missing but get resolv= ed by the library instances or even worse libraries pulled in by the librar= ies. So it looks to me like it is a missing Depex in the driver. Not all instances of the library, that are v= alid for the module, imply the dependency. 

 

/Volumes/Case/edk2(master)>git grep PcdLib -- *.inf | grep LIBRARY_CLASS

MdePkg/Library/BasePcdLibNull/BasePcdLibNull.i= nf:21:  LIBRARY_CLASS              =     =3D PcdLib

MdePkg/Library/DxePcdLib/DxePcdLib.inf:35:&nbs= p; LIBRARY_CLASS                &nb= sp; =3D PcdLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CO= RE UEFI_APPLICATION UEFI_DRIVER

MdePkg/Library/PeiPcdLib/PeiPcdLib.inf:32:&nbs= p; LIBRARY_CLASS                &nb= sp; =3D PcdLib|PEIM PEI_CORE SEC



The easiest way to debug these kind of problems is = to generate a report file by passing `-y REPORTFILE` to build. For my = projects I usually always build a report file and dump it into the Build re= sults directory. This will show what libraries got linked in, and what the actual dependency expression resolved to.&nbs= p;

 



Should I/we try to remove the APRIORI entries fro= m OVMF in a similar way?


Let's get to the bottom of this first. Laszlo may remember why exactly tho= se entries are there in the first place, and I suspect it is a different is= sue.

 

It is good to get the history. In general the APRIO= RI files are used to force a dispatch order for debugging, like getting sta= tus codes or serial output quicker. 

 

From an architectural point of view the dispatch or= der is only defined as "if your Depex is TRUE you can be dispatched&qu= ot;. So they APRORI file lets you define the undefined behavior. The implem= entation happens to walk the FV in order  and will dispatch and drivers with a Depex of TRUE and keep iterating until a= ll the Depex'es are TRUE or all the drivers dispatch. In the "good old= days" we would sort the PEIMs in dispatch order so that everything wo= uld dispatch on the 1st pass to reduce the number of slow FLASH reads required to boot. 

 

Thanks,

 

Andrew Fish



 

 

--_000_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_-- --_004_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_ Content-Type: image/png; name="3C121AAE0A3549E984277926BF20E545.png" Content-Description: 3C121AAE0A3549E984277926BF20E545.png Content-Disposition: inline; filename="3C121AAE0A3549E984277926BF20E545.png"; size=140; creation-date="Thu, 07 May 2020 16:45:50 GMT"; modification-date="Thu, 07 May 2020 16:45:50 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAsUAAAABCAYAAAA2LdOTAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAhSURBVEhL7cMBDQAACAMg+5cygQkeRoMIG9WT VVXVv7MHBORqBklJA7cAAAAASUVORK5CYII= --_004_CY4PR21MB07432F6F0A597C94C28AFDACEFA50CY4PR21MB0743namp_--