You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At first sight, nothing in those lines seems particularly suspicious. Annoyingly, we can not profile any further as the GetPerformanceCounter() method returns zero until we call the AcpiTimerLib constructor as part of ProcessLibraryConstructor at the very end of the linked code block. Thus, we still have no way to further discern where the overheads are coming from.
Note
The ProcessLibraryConstructor method is auto-generated during compilation, and can be found in the ./Build directory.
In my case, the file is located here: Build/AmdSev/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c.
The text was updated successfully, but these errors were encountered:
According to the plot below, the biggest difference between SEV and non-SEV OVMF boots is in the
MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
method.In particular, in these lines of OVMF code..
At first sight, nothing in those lines seems particularly suspicious. Annoyingly, we can not profile any further as the
GetPerformanceCounter()
method returns zero until we call theAcpiTimerLib
constructor as part ofProcessLibraryConstructor
at the very end of the linked code block. Thus, we still have no way to further discern where the overheads are coming from.Note
The
ProcessLibraryConstructor
method is auto-generated during compilation, and can be found in the./Build
directory.In my case, the file is located here:
Build/AmdSev/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c
.The text was updated successfully, but these errors were encountered: