Date   

回复: [edk2-discuss] GCD initialization and memory allocation HOBs

gaoliming
 

Jeff:

-----邮件原件-----
发件人: bounce+34241+372+4905953+8764802@groups.io
<bounce+34241+372+4905953+8764802@groups.io> 代表 Jeff Brasen
发送时间: 2020年9月26日 1:08
收件人: discuss@edk2.groups.io; lersek@redhat.com
主题: Re: [edk2-discuss] GCD initialization and memory allocation HOBs

#2 is the case we are in, we have data that is loaded by our pre-UEFI
bootloaders into memory that should behave as boot services memory (OS
can reclaim this) When we setup our HOB list we added a normal system
memory resource that covers both the HOB list and this other data. We then
add a memory allocation HOB to mark this memory as boot services data. We
are seeing cases where CoreInitializeMemoryServices Is selecting the region
that has this data and is both causing corruption as well as preventing the
memory allocation hob from being processed correctly as the memory is not
free when GCD parses it.
You mean the memory range specified by PHIT resource hob is selected by CoreInitializeMemoryServices().
This memory range includes PEI memory and the allocated memory. So, there is no
free memory in this memory range. After CoreInitializeMemoryServices(), do you meet with memory allocation failure?

Can you attach the failure boot log for further analysis?

Thanks
Liming
We can easily work around this particular issue by splitting the system
memory resource so that GCD then goes to look for space in the free region in
the hob or at the beginning of the resource that contains the HOB list. But if
we don't have enough space in those regions then it will look for other
memory regions and it doesn't seem like the best practice to design the HOB
producer with the specific implementation of GCD services.

It seems that if we have memory allocation data that is in outside the HOB list
itself we could hit this problem, and this seems valid per my reading of the PI
spec.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, September 25, 2020 3:06 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Cc: Jan Bobek <jbobek@nvidia.com>; Ashish Singhal
<ashishsingha@nvidia.com>
Subject: Re: [edk2-discuss] GCD initialization and memory allocation HOBs

External email: Use caution opening links or attachments


On 09/24/20 20:40, Jeff Brasen wrote:
It looks like CoreInitializeMemoryServices
(https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229
c
ec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116)
does not honor any memory allocations outside of the HOB list itself.
Should we add code to this function to make sure the region this
function select does not end up over a reserved region that the HOB
producer phase marked as already allocated? Either that or codify the
specific requirements a bit more on to make sure cases like this are
invalid. (producer might have to split up system resource entries,
etc)
Do you mean

(1) a physically reserved memory address range
(EFI_RESOURCE_MEMORY_RESERVED), or

(2) normal RAM (EFI_RESOURCE_SYSTEM_MEMORY) that is meant to be
"repurposed" (= pre-allocated) in PEI as a particular UEFI memory type?

EFI_HOB_RESOURCE_DESCRIPTOR "does not describe how memory is used
but instead describes the attributes of the physical memory present".

CoreInitializeMemoryServices() honors (1).

CoreInitializeMemoryServices() does not honor (2); however, the later
function CoreInitializeGcdServices() does honor (2).


* Regarding (1):

My understanding is that the HOB producer phase should describe "physically
reserved" memory regions with EFI_RESOURCE_MEMORY_RESERVED
resource descriptor HOBs, and these should not overlap normal memory
regions, which are described with EFI_RESOURCE_SYSTEM_MEMORY
descriptor HOBs.

Furthermore, whether (a part of) a memory resource is allocated or not, is
*orthogonal* to whether the memory resource is "physically reserved
memory" or "normal RAM". In my opinion, the diagram at

PI 1.7
Volume 2 (DXE Core Interface)
7.2.2 GCD Memory Resources
Figure 2. GCD Memory State Transitions

applies.

So the HOB producer phase should firstly describe the area in question as
EFI_RESOURCE_MEMORY_RESERVED (without overlapping any other
resource descriptor in memory address space).

Secondly, if the HOB producer phase wants to prevent DXE modules from
allocating reserved memory out of this resource, then the HOB producer
phase should *also* cover the entire range with a memalloc HOB that uses
EfiReservedMemoryType.

The first step above (= describing the area with an
EFI_RESOURCE_MEMORY_RESERVED HOB) will activate the following branch
in
CoreInitializeMemoryServices():

//
// Skip Resource Descriptor HOBs that do not describe tested system
memory
//
ResourceHob = Hob.ResourceDescriptor;
if (ResourceHob->ResourceType !=
EFI_RESOURCE_SYSTEM_MEMORY) {
continue;
}

* Regarding (2):

Normal (= not physically reserved) RAM that is allocated in PEI -- using
memalloc HOBs with various UEFI memory types, such as BS Data or AcpiNVS
-- is set aside in the CoreInitializeGcdServices() function.

Is that too late for your purpose? If so, why?

AIUI, CoreInitializeGcdServices() does make sure that DXE-phase calls to
gDS->AllocateMemorySpace(), gBS->AllocatePool(), and friends, will not
trample over the original memalloc HOBs.

Thanks,
Laszlo










Re: how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

Laszlo Ersek
 

On 09/28/20 10:57, wenyi,xie via groups.io wrote:
Hi, all
I use edk2-stable201903 in my project and meet a compile warning like below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option,
Architecture(s) = AARCH64
Build target = RELEASE
Toolchain = GCC5
The UefiDriverEntryPoint lib class in the [Sources] section in
"ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" should be resolved by your
platform DSC to
"MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf".

That's where the definition of _ModuleEntryPoint() should come from (see
"MdePkg/Library/UefiDriverEntryPoint/DriverEntryPoint.c").

Thanks
Laszlo


Re: compile warning from BaseTools

Laszlo Ersek
 

On 09/28/20 16:10, wenyi,xie via groups.io wrote:
Hi all,
I meet some compile warning in BaseTools,the version of EDK2 is edk2-stable201903, as I am not familiar with Antlr grammer, I don't know how to fix it.
Could someone give me a hand, thanks!

VfrSyntax.g, line 2018: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 2023: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 3651: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3660: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3669: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3679: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3709: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3718: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
I think I've always just ignored these...

Laszlo


compile warning from BaseTools

wenyi,xie
 

Hi all,
I meet some compile warning in BaseTools,the version of EDK2 is edk2-stable201903, as I am not familiar with Antlr grammer, I don't know how to fix it.
Could someone give me a hand, thanks!

VfrSyntax.g, line 2018: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 2023: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 3651: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3660: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3669: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3679: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3709: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3718: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )


how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

wenyi,xie
 

Hi, all
I use edk2-stable201903 in my project and meet a compile warning like below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option,
Architecture(s) = AARCH64
Build target = RELEASE
Toolchain = GCC5


Re: GCD initialization and memory allocation HOBs

Jeff Brasen
 

#2 is the case we are in, we have data that is loaded by our pre-UEFI bootloaders into memory that should behave as boot services memory (OS can reclaim this) When we setup our HOB list we added a normal system memory resource that covers both the HOB list and this other data. We then add a memory allocation HOB to mark this memory as boot services data. We are seeing cases where CoreInitializeMemoryServices Is selecting the region that has this data and is both causing corruption as well as preventing the memory allocation hob from being processed correctly as the memory is not free when GCD parses it.

We can easily work around this particular issue by splitting the system memory resource so that GCD then goes to look for space in the free region in the hob or at the beginning of the resource that contains the HOB list. But if we don't have enough space in those regions then it will look for other memory regions and it doesn't seem like the best practice to design the HOB producer with the specific implementation of GCD services.

It seems that if we have memory allocation data that is in outside the HOB list itself we could hit this problem, and this seems valid per my reading of the PI spec.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, September 25, 2020 3:06 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Cc: Jan Bobek <jbobek@nvidia.com>; Ashish Singhal <ashishsingha@nvidia.com>
Subject: Re: [edk2-discuss] GCD initialization and memory allocation HOBs

External email: Use caution opening links or attachments


On 09/24/20 20:40, Jeff Brasen wrote:
It looks like CoreInitializeMemoryServices
(https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229c
ec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116)
does not honor any memory allocations outside of the HOB list itself.
Should we add code to this function to make sure the region this
function select does not end up over a reserved region that the HOB
producer phase marked as already allocated? Either that or codify the
specific requirements a bit more on to make sure cases like this are
invalid. (producer might have to split up system resource entries,
etc)
Do you mean

(1) a physically reserved memory address range (EFI_RESOURCE_MEMORY_RESERVED), or

(2) normal RAM (EFI_RESOURCE_SYSTEM_MEMORY) that is meant to be "repurposed" (= pre-allocated) in PEI as a particular UEFI memory type?

EFI_HOB_RESOURCE_DESCRIPTOR "does not describe how memory is used but instead describes the attributes of the physical memory present".

CoreInitializeMemoryServices() honors (1).

CoreInitializeMemoryServices() does not honor (2); however, the later function CoreInitializeGcdServices() does honor (2).


* Regarding (1):

My understanding is that the HOB producer phase should describe "physically reserved" memory regions with EFI_RESOURCE_MEMORY_RESERVED resource descriptor HOBs, and these should not overlap normal memory regions, which are described with EFI_RESOURCE_SYSTEM_MEMORY descriptor HOBs.

Furthermore, whether (a part of) a memory resource is allocated or not, is *orthogonal* to whether the memory resource is "physically reserved memory" or "normal RAM". In my opinion, the diagram at

PI 1.7
Volume 2 (DXE Core Interface)
7.2.2 GCD Memory Resources
Figure 2. GCD Memory State Transitions

applies.

So the HOB producer phase should firstly describe the area in question as EFI_RESOURCE_MEMORY_RESERVED (without overlapping any other resource descriptor in memory address space).

Secondly, if the HOB producer phase wants to prevent DXE modules from allocating reserved memory out of this resource, then the HOB producer phase should *also* cover the entire range with a memalloc HOB that uses EfiReservedMemoryType.

The first step above (= describing the area with an EFI_RESOURCE_MEMORY_RESERVED HOB) will activate the following branch in
CoreInitializeMemoryServices():

//
// Skip Resource Descriptor HOBs that do not describe tested system memory
//
ResourceHob = Hob.ResourceDescriptor;
if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY) {
continue;
}

* Regarding (2):

Normal (= not physically reserved) RAM that is allocated in PEI -- using memalloc HOBs with various UEFI memory types, such as BS Data or AcpiNVS
-- is set aside in the CoreInitializeGcdServices() function.

Is that too late for your purpose? If so, why?

AIUI, CoreInitializeGcdServices() does make sure that DXE-phase calls to
gDS->AllocateMemorySpace(), gBS->AllocatePool(), and friends, will not
trample over the original memalloc HOBs.

Thanks,
Laszlo


Re: GCD initialization and memory allocation HOBs

Laszlo Ersek
 

On 09/24/20 20:40, Jeff Brasen wrote:
It looks like CoreInitializeMemoryServices
(https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229cec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116)
does not honor any memory allocations outside of the HOB list itself.
Should we add code to this function to make sure the region this
function select does not end up over a reserved region that the HOB
producer phase marked as already allocated? Either that or codify the
specific requirements a bit more on to make sure cases like this are
invalid. (producer might have to split up system resource entries,
etc)
Do you mean

(1) a physically reserved memory address range
(EFI_RESOURCE_MEMORY_RESERVED), or

(2) normal RAM (EFI_RESOURCE_SYSTEM_MEMORY) that is meant to be
"repurposed" (= pre-allocated) in PEI as a particular UEFI memory type?


EFI_HOB_RESOURCE_DESCRIPTOR "does not describe how memory is used but
instead describes the attributes of the physical memory present".

CoreInitializeMemoryServices() honors (1).

CoreInitializeMemoryServices() does not honor (2); however, the later
function CoreInitializeGcdServices() does honor (2).


* Regarding (1):

My understanding is that the HOB producer phase should describe
"physically reserved" memory regions with EFI_RESOURCE_MEMORY_RESERVED
resource descriptor HOBs, and these should not overlap normal memory
regions, which are described with EFI_RESOURCE_SYSTEM_MEMORY descriptor
HOBs.

Furthermore, whether (a part of) a memory resource is allocated or not,
is *orthogonal* to whether the memory resource is "physically reserved
memory" or "normal RAM". In my opinion, the diagram at

PI 1.7
Volume 2 (DXE Core Interface)
7.2.2 GCD Memory Resources
Figure 2. GCD Memory State Transitions

applies.

So the HOB producer phase should firstly describe the area in question
as EFI_RESOURCE_MEMORY_RESERVED (without overlapping any other resource
descriptor in memory address space).

Secondly, if the HOB producer phase wants to prevent DXE modules from
allocating reserved memory out of this resource, then the HOB producer
phase should *also* cover the entire range with a memalloc HOB
that uses EfiReservedMemoryType.

The first step above (= describing the area with an
EFI_RESOURCE_MEMORY_RESERVED HOB) will activate the following branch in
CoreInitializeMemoryServices():

//
// Skip Resource Descriptor HOBs that do not describe tested system memory
//
ResourceHob = Hob.ResourceDescriptor;
if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY) {
continue;
}

* Regarding (2):

Normal (= not physically reserved) RAM that is allocated in PEI -- using
memalloc HOBs with various UEFI memory types, such as BS Data or AcpiNVS
-- is set aside in the CoreInitializeGcdServices() function.

Is that too late for your purpose? If so, why?

AIUI, CoreInitializeGcdServices() does make sure that DXE-phase calls to
gDS->AllocateMemorySpace(), gBS->AllocatePool(), and friends, will not
trample over the original memalloc HOBs.

Thanks,
Laszlo


GCD initialization and memory allocation HOBs

Jeff Brasen
 

It looks like CoreInitializeMemoryServices (https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229cec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116) does not honor any memory allocations outside of the HOB list itself. Should we add code to this function to make sure the region this function select does not end up over a reserved region that the HOB producer phase marked as already allocated? Either that or codify the specific requirements a bit more on to make sure cases like this are invalid. (producer might have to split up system resource entries, etc)

We can work on a change if we decide that we want to improve GCD but wanted to get feedback before we started on this.

Thanks,
Jeff


Build failure because of the new dependency

Zhiguang Liu
 

Hi, Matthew,
I notice the below change has broken Intel platform build or module build whichever uses OpensslLib(Crypto).inf, because it can't find the new dependency RngLib
I understand there may be many platforms to fix and may take some time. If you have time, could you please fix this issue? Thanks a lot.

Thanks
Zhiguang

SHA-1: b5701a4c7a0fb185e0c5b9db9525939c78664bfd

* CryptoPkg: OpensslLib: Use RngLib to generate entropy in rand_pool

Ref: https://github.com/tianocore/edk2/pull/845
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871

Changes OpenSSL to no longer depend on TimerLib and instead use RngLib.
This allows platforms to decide for themsevles what sort of entropy source
they provide to OpenSSL and TlsLib.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>

Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>


Re: ESRT in OVMF

Sandeep Dhanvada
 

Hi,

I am able to upgrade firmware using CaspsuleApp.efi with the help of Tomas Pilar in other thread in this mailing list.

however, i have some modifications in edk2 source code for this to happen. please let me know what is the process for sending patches to mailing list.

Thanks,
Sandeep


Re: when bug 2002 will be fixed

wenyi,xie
 

Hi Zhiguang,

I see. Thank you for your reply.

Regards
Wenyi

On 2020/9/16 17:03, Liu, Zhiguang wrote:
Hi Wenyi,

I have sent patch for review and get some comments.
https://edk2.groups.io/g/devel/message/61324
And I still need some time to enhance this patch.

Thanks
Zhiguang

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, September 16, 2020 4:55 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] when bug 2002 will be fixed

Hi, all
May I ask when bug 2002 will be fixed, what's the status now?
Bug 2002 SMM pointer leak in SmmVariableGetStatistics()
https://bugzilla.tianocore.org/show_bug.cgi?id=2002




Re: when bug 2002 will be fixed

Zhiguang Liu
 

Hi Wenyi,

I have sent patch for review and get some comments.
https://edk2.groups.io/g/devel/message/61324
And I still need some time to enhance this patch.

Thanks
Zhiguang

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, September 16, 2020 4:55 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] when bug 2002 will be fixed

Hi, all
May I ask when bug 2002 will be fixed, what's the status now?
Bug 2002 SMM pointer leak in SmmVariableGetStatistics()
https://bugzilla.tianocore.org/show_bug.cgi?id=2002




when bug 2002 will be fixed

wenyi,xie
 

Hi, all
May I ask when bug 2002 will be fixed, what's the status now?
Bug 2002 SMM pointer leak in SmmVariableGetStatistics()
https://bugzilla.tianocore.org/show_bug.cgi?id=2002


Re: Is it valid to use DEC_VERSION instead of DEC_SPECIFICATION in dec file

wenyi,xie
 

Hi, Laszlo,

Thank you for your confirming, I will send a patch soon.

Regards
Wenyi

On 2020/9/10 20:59, Laszlo Ersek wrote:
On 09/10/20 09:27, wenyi,xie via groups.io wrote:
I found DEC_VERSION is used in [Defines] section in EmulatorPkg.dec, but I checked the code in BaseTools and found DEC_VERSION can't be parsed.
Right, the edk2 DEC specification document only knows about
DEC_SPECIFICATION too. Please file a bug, or send a patch, for
"EmulatorPkg.dec".

Thanks,
Laszlo


Re: Is it valid to use DEC_VERSION instead of DEC_SPECIFICATION in dec file

Laszlo Ersek
 

On 09/10/20 09:27, wenyi,xie via groups.io wrote:
I found DEC_VERSION is used in [Defines] section in EmulatorPkg.dec, but I checked the code in BaseTools and found DEC_VERSION can't be parsed.
Right, the edk2 DEC specification document only knows about
DEC_SPECIFICATION too. Please file a bug, or send a patch, for
"EmulatorPkg.dec".

Thanks,
Laszlo


Is it valid to use DEC_VERSION instead of DEC_SPECIFICATION in dec file

wenyi,xie
 

I found DEC_VERSION is used in [Defines] section in EmulatorPkg.dec, but I checked the code in BaseTools and found DEC_VERSION can't be parsed.


Re: loop in CoreCheckTimers

Stanley Gan
 

Hi Laszlo,
Thanks for your reply.
I mean " CoreSignalEvent (mEfiCheckTimerEvent)" in CoreCheckTimers is not
necessary.
Because all timer event already signified in CoreCheckTimers 1st run. We
don't need to run CoreCheckTimers again.
I actually add Commit 239b50a86370 to my project. It can solve my problem.
But I don't think it's a good long term solution. It's not the root cause
of the issue.

On Mon, Sep 7, 2020 at 7:39 PM Laszlo Ersek <lersek@redhat.com> wrote:

(CC Jeff)

On 09/07/20 02:29, Stanley Gan wrote:
Hi All,



I have some questions about MdeModulePkg\Core\Dxe\Event\Timer.c
CoreCheckTimers.

My system will keep looping in CoreCheckTimers in some scenarios:

· CPU run very slow (Cache disabled)

· A lot of timer event (Network stack enabled)

In normal boot, CoreCheckTimers will execute two times. 1st time, it
actually signifies timer event. 2nd time, because there is no expired
timer, it will exit quickly.

In my scenario, another time interrupt comes and updates EfiSystemTime at
second CoreCheckTimers. The system will keep looping in CoreCheckTimers.

My questions are:

1. Is the red line below necessary?
What do you mean by "red line"?

Can we disable interrupt at TPL
30?

//

// If that's before now, then reset the timer to start from now

//

if (Event->Timer.TriggerTime <= SystemTime) {

Event->Timer.TriggerTime = SystemTime;

CoreSignalEvent (mEfiCheckTimerEvent);

}

2. If the system runs slowly, do we need to expand the timer
interrupt interval? Is there any golden standard about the ratio between
CPU speed and timer interval?
Perhaps related: commit 239b50a86370 ("OvmfPkg: End timer interrupt
later to avoid stack overflow under load", 2020-06-18).

Thanks,
Laszlo


Re: loop in CoreCheckTimers

Laszlo Ersek
 

(CC Jeff)

On 09/07/20 02:29, Stanley Gan wrote:
Hi All,



I have some questions about MdeModulePkg\Core\Dxe\Event\Timer.c
CoreCheckTimers.

My system will keep looping in CoreCheckTimers in some scenarios:

· CPU run very slow (Cache disabled)

· A lot of timer event (Network stack enabled)

In normal boot, CoreCheckTimers will execute two times. 1st time, it
actually signifies timer event. 2nd time, because there is no expired
timer, it will exit quickly.

In my scenario, another time interrupt comes and updates EfiSystemTime at
second CoreCheckTimers. The system will keep looping in CoreCheckTimers.

My questions are:

1. Is the red line below necessary?
What do you mean by "red line"?

Can we disable interrupt at TPL
30?

//

// If that's before now, then reset the timer to start from now

//

if (Event->Timer.TriggerTime <= SystemTime) {

Event->Timer.TriggerTime = SystemTime;

CoreSignalEvent (mEfiCheckTimerEvent);

}

2. If the system runs slowly, do we need to expand the timer
interrupt interval? Is there any golden standard about the ratio between
CPU speed and timer interval?
Perhaps related: commit 239b50a86370 ("OvmfPkg: End timer interrupt
later to avoid stack overflow under load", 2020-06-18).

Thanks,
Laszlo


loop in CoreCheckTimers

Stanley Gan
 

Hi All,



I have some questions about MdeModulePkg\Core\Dxe\Event\Timer.c
CoreCheckTimers.

My system will keep looping in CoreCheckTimers in some scenarios:

· CPU run very slow (Cache disabled)

· A lot of timer event (Network stack enabled)

In normal boot, CoreCheckTimers will execute two times. 1st time, it
actually signifies timer event. 2nd time, because there is no expired
timer, it will exit quickly.

In my scenario, another time interrupt comes and updates EfiSystemTime at
second CoreCheckTimers. The system will keep looping in CoreCheckTimers.

My questions are:

1. Is the red line below necessary? Can we disable interrupt at TPL
30?

//

// If that's before now, then reset the timer to start from now

//

if (Event->Timer.TriggerTime <= SystemTime) {

Event->Timer.TriggerTime = SystemTime;

CoreSignalEvent (mEfiCheckTimerEvent);

}

2. If the system runs slowly, do we need to expand the timer
interrupt interval? Is there any golden standard about the ratio between
CPU speed and timer interval?


Re: THe driver image handle

Laszlo Ersek
 

On 09/04/20 13:04, Tomas Pilar (tpilar) wrote:
Hi Libo,

The convention says that when a driver manages a device, it should find the
relevant IO protocol installed on the device handle (for example a PCI
device will have EFI_PCI_IO_PROTOCOL) and open it using
the EFI_OPEN_PROTOCOL_BY_DRIVER attribute. The driver will keep the
protocol open for the entire duration while it manages the device. You can
use boot services (UefiBootServicesTableLib.h), in particular the
gBS->OpenProtocolInformation() function, to inspect who has a specific
protocol on a specific handle open and with what attributes.

Now, if you are a user and you boot into UEFI shell, all you have to do is
inspect the (shell) handle using the 'dh -d -v <handle>' command.
See also the EfiTestManagedDevice() and EfiTestChildHandle() utility
functions in UefiLib.

Thanks
Laszlo

521 - 540 of 892