Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Marvin H?user 
Hey all,

IScsiMisc and Snp (latter not part of V1) are the only code files I found using 
these services during the event (within MdeModulePkg). A patch for NetworkPkg's 
IScsiMisc has already been submitted and it still open for review from my side.
If anyone has found any other example, feel free to make a patch of your own 
including the ones mentioned above, or - if you prefer not to - please reply 
mentioning them so I can include them in a V2 late this or maybe next week.

Regards,
Marvin.

> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, June 22, 2016 9:55 PM
> To: Marvin H?user <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> FreePool() during ExitBS().
> 
> Marvin,
> 
> Yes.  A V2 version of the patch that eliminates memory alloc/free actions in
> exit boot services event notification functions looks like a very good idea to
> me.
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Wednesday, June 22, 2016 12:32 PM
> > To: edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > FreePool() during ExitBS().
> >
> > Hey Mike,
> >
> > Yes, I'm aware of that and it has been the very reason for this patch.
> > Despite doing the same for SMM memory, which is nonsense (I just
> > didn't think about it being separate, sorry again), I still would like
> > to have feedback of the changes to IScsiMisc.c - there it's the same
> > situation, but with non-SMM memory, so memory that does alter the UEFI
> Memory Map.
> >
> > Regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > > Sent: Wednesday, June 22, 2016 9:10 PM
> > > To: Marvin H?user <marvin.haeu...@outlook.com>; edk2-
> > > de...@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> > > Cc: Zeng, Star <star.z...@intel.com>
> > > Subject: RE: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > > FreePool() during ExitBS().
> > >
> > > Marvin,
> > >
> > > If none of the exit boot services event handlers in a platform do
> > > any memory allocation/free actions, then only a single call to
> > > GetMemoryMap() is required because the memory map key will be the
> same.
> > >
> > > As Andrew pointed out, these event notifications should not do
> > > alloc/free, so if there are exit boot services notification
> > > functions that are doing alloc/free then those should be cleaned up.
> > >
> > > Are there any specific code change requests here?
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > > > Behalf Of Marvin H?user
> > > > Sent: Wednesday, June 22, 2016 4:27 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Zeng, Star <star.z...@intel.com>
> > > > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > > > FreePool() during ExitBS().
> > > >
> > > > Hey Star,
> > > >
> > > > > I am still curious what is the real issue Marvin met.
> > > >
> > > > There is no issue I met, I simply want to save another call to
> > > > GetMemoryMap() because it may be altered during ExitBS(). It's a
> > > > break of the specification, but it sounds like Intel complying to
> > > > its own
> > > sepcification is not a good-enough reason...
> > > >
> > > > Regards,
> > > > Marvin.
> > > >
> > > > > -Original Message-
> > > > > From: Zeng, Star [mailto:star.z...@intel.com]
> > > > > Sent: Wednesday, June 22, 2016 11:18 AM
> > > > > To: Bruce Cran <br...@cran.org.uk>; marvin.haeu...@outlook.com;
> > > > > edk2- de...@lists.01.org
> > > > > Cc: Tian, Feng <feng.t...@intel.com>
> > > > > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage
> > > > > of
> > > > > FreePool() during ExitBS().
> > > > >
> > > > > On 2016/6/22 13:39, Bruce Cran wrote

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Kinney, Michael D 
Marvin,

Yes.  A V2 version of the patch that eliminates memory alloc/free actions in 
exit 
boot services event notification functions looks like a very good idea to me.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
> H?user
> Sent: Wednesday, June 22, 2016 12:32 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() 
> during
> ExitBS().
> 
> Hey Mike,
> 
> Yes, I'm aware of that and it has been the very reason for this patch. 
> Despite doing
> the same for SMM memory, which is nonsense (I just didn't think about it being
> separate, sorry again), I still would like to have feedback of the changes to
> IScsiMisc.c - there it's the same situation, but with non-SMM memory, so 
> memory that
> does alter the UEFI Memory Map.
> 
> Regards,
> Marvin.
> 
> > -Original Message-
> > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> > Sent: Wednesday, June 22, 2016 9:10 PM
> > To: Marvin H?user <marvin.haeu...@outlook.com>; edk2-
> > de...@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> > Cc: Zeng, Star <star.z...@intel.com>
> > Subject: RE: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > FreePool() during ExitBS().
> >
> > Marvin,
> >
> > If none of the exit boot services event handlers in a platform do any memory
> > allocation/free actions, then only a single call to GetMemoryMap() is
> > required because the memory map key will be the same.
> >
> > As Andrew pointed out, these event notifications should not do alloc/free,
> > so if there are exit boot services notification functions that are doing
> > alloc/free then those should be cleaned up.
> >
> > Are there any specific code change requests here?
> >
> > Mike
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > > Marvin H?user
> > > Sent: Wednesday, June 22, 2016 4:27 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Zeng, Star <star.z...@intel.com>
> > > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > > FreePool() during ExitBS().
> > >
> > > Hey Star,
> > >
> > > > I am still curious what is the real issue Marvin met.
> > >
> > > There is no issue I met, I simply want to save another call to
> > > GetMemoryMap() because it may be altered during ExitBS(). It's a break
> > > of the specification, but it sounds like Intel complying to its own
> > sepcification is not a good-enough reason...
> > >
> > > Regards,
> > > Marvin.
> > >
> > > > -Original Message-
> > > > From: Zeng, Star [mailto:star.z...@intel.com]
> > > > Sent: Wednesday, June 22, 2016 11:18 AM
> > > > To: Bruce Cran <br...@cran.org.uk>; marvin.haeu...@outlook.com;
> > > > edk2- de...@lists.01.org
> > > > Cc: Tian, Feng <feng.t...@intel.com>
> > > > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > > > FreePool() during ExitBS().
> > > >
> > > > On 2016/6/22 13:39, Bruce Cran wrote:
> > > > > On 6/19/16 9:21 PM, Zeng, Star wrote:
> > > > >
> > > > >> 1. The memory allocate and free in PiSmmCore are SMRAM that is
> > > > >> not related to UEFI memory map.
> > > > >> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
> > > > >> should have got the memory map before ExitBootServices.
> > > > >> That means the memory free should not impact the memory map
> > *got
> > > > >> by UEFI OS loader*, it will only impact the memory map if the
> > > > >> UEFI OS loader will call GetMemoryMap() again.
> > > > >
> > > > >
> > > > > I just found the following post about Linux and how it calls
> > > > > ExitBootServices, which may be relevant:
> > > > >
> > > > > http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBoo
> > > > > tSer
> > > > > vices-on-failure-td664938.html
> > > > >
> > > > >
> > > > > "ExitBootServices is absolutely supposed to return a failure if
> > > > > any ExitBootServices event handler changes the memory map.
> > > > >

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Marvin H?user 
Hey Mike,

Yes, I'm aware of that and it has been the very reason for this patch. Despite 
doing the same for SMM memory, which is nonsense (I just didn't think about it 
being separate, sorry again), I still would like to have feedback of the 
changes to IScsiMisc.c - there it's the same situation, but with non-SMM 
memory, so memory that does alter the UEFI Memory Map.

Regards,
Marvin.

> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Wednesday, June 22, 2016 9:10 PM
> To: Marvin H?user <marvin.haeu...@outlook.com>; edk2-
> de...@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> FreePool() during ExitBS().
> 
> Marvin,
> 
> If none of the exit boot services event handlers in a platform do any memory
> allocation/free actions, then only a single call to GetMemoryMap() is
> required because the memory map key will be the same.
> 
> As Andrew pointed out, these event notifications should not do alloc/free,
> so if there are exit boot services notification functions that are doing
> alloc/free then those should be cleaned up.
> 
> Are there any specific code change requests here?
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Marvin H?user
> > Sent: Wednesday, June 22, 2016 4:27 AM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.z...@intel.com>
> > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > FreePool() during ExitBS().
> >
> > Hey Star,
> >
> > > I am still curious what is the real issue Marvin met.
> >
> > There is no issue I met, I simply want to save another call to
> > GetMemoryMap() because it may be altered during ExitBS(). It's a break
> > of the specification, but it sounds like Intel complying to its own
> sepcification is not a good-enough reason...
> >
> > Regards,
> > Marvin.
> >
> > > -Original Message-
> > > From: Zeng, Star [mailto:star.z...@intel.com]
> > > Sent: Wednesday, June 22, 2016 11:18 AM
> > > To: Bruce Cran <br...@cran.org.uk>; marvin.haeu...@outlook.com;
> > > edk2- de...@lists.01.org
> > > Cc: Tian, Feng <feng.t...@intel.com>
> > > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > > FreePool() during ExitBS().
> > >
> > > On 2016/6/22 13:39, Bruce Cran wrote:
> > > > On 6/19/16 9:21 PM, Zeng, Star wrote:
> > > >
> > > >> 1. The memory allocate and free in PiSmmCore are SMRAM that is
> > > >> not related to UEFI memory map.
> > > >> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
> > > >> should have got the memory map before ExitBootServices.
> > > >> That means the memory free should not impact the memory map
> *got
> > > >> by UEFI OS loader*, it will only impact the memory map if the
> > > >> UEFI OS loader will call GetMemoryMap() again.
> > > >
> > > >
> > > > I just found the following post about Linux and how it calls
> > > > ExitBootServices, which may be relevant:
> > > >
> > > > http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBoo
> > > > tSer
> > > > vices-on-failure-td664938.html
> > > >
> > > >
> > > > "ExitBootServices is absolutely supposed to return a failure if
> > > > any ExitBootServices event handler changes the memory map.
> > > > Basically the get_map loop should run again if ExitBootServices
> > > > returns an error the first time.  I would say it would be fair
> > > > that if ExitBootServices gives an error the second time then Linux
> > > > would be fine in returning control back to BIOS."
> > > >
> > >
> > > Good information that does not assume ExitBootServices event
> > > handlers are not using memory allocation services.
> > > In reality, the CoreExitBootServices() in DxeMain.c of EDK2 will
> > > never return error after calling CoreNotifySignalList
> ().
> > >
> > > I am still curious what is the real issue Marvin met.
> > >
> > > If we are going to clean up, we may need to review all the
> > > ExitBootServices event handlers to see if they are using memory
> > > allocation services directly or indirectly and find the method to clean up
> them.
> > >
> > > Cc more related people.
> > >
> > > Thanks,
> > > Star
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Kinney, Michael D 
Marvin,

If none of the exit boot services event handlers in a platform do any memory 
allocation/free
actions, then only a single call to GetMemoryMap() is required because the 
memory map key
will be the same.

As Andrew pointed out, these event notifications should not do alloc/free, so 
if there
are exit boot services notification functions that are doing alloc/free then 
those should
be cleaned up.

Are there any specific code change requests here?

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
> H?user
> Sent: Wednesday, June 22, 2016 4:27 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() 
> during
> ExitBS().
> 
> Hey Star,
> 
> > I am still curious what is the real issue Marvin met.
> 
> There is no issue I met, I simply want to save another call to GetMemoryMap() 
> because
> it may be altered during ExitBS(). It's a break of the specification, but it 
> sounds
> like Intel complying to its own sepcification is not a good-enough reason...
> 
> Regards,
> Marvin.
> 
> > -Original Message-
> > From: Zeng, Star [mailto:star.z...@intel.com]
> > Sent: Wednesday, June 22, 2016 11:18 AM
> > To: Bruce Cran <br...@cran.org.uk>; marvin.haeu...@outlook.com; edk2-
> > de...@lists.01.org
> > Cc: Tian, Feng <feng.t...@intel.com>
> > Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> > FreePool() during ExitBS().
> >
> > On 2016/6/22 13:39, Bruce Cran wrote:
> > > On 6/19/16 9:21 PM, Zeng, Star wrote:
> > >
> > >> 1. The memory allocate and free in PiSmmCore are SMRAM that is not
> > >> related to UEFI memory map.
> > >> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
> > >> should have got the memory map before ExitBootServices.
> > >> That means the memory free should not impact the memory map *got by
> > >> UEFI OS loader*, it will only impact the memory map if the UEFI OS
> > >> loader will call GetMemoryMap() again.
> > >
> > >
> > > I just found the following post about Linux and how it calls
> > > ExitBootServices, which may be relevant:
> > >
> > > http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBootSer
> > > vices-on-failure-td664938.html
> > >
> > >
> > > "ExitBootServices is absolutely supposed to return a failure if any
> > > ExitBootServices event handler changes the memory map.  Basically the
> > > get_map loop should run again if ExitBootServices returns an error the
> > > first time.  I would say it would be fair that if ExitBootServices
> > > gives an error the second time then Linux would be fine in returning
> > > control back to BIOS."
> > >
> >
> > Good information that does not assume ExitBootServices event handlers are
> > not using memory allocation services.
> > In reality, the CoreExitBootServices() in DxeMain.c of EDK2 will never 
> > return
> > error after calling CoreNotifySignalList ().
> >
> > I am still curious what is the real issue Marvin met.
> >
> > If we are going to clean up, we may need to review all the ExitBootServices
> > event handlers to see if they are using memory allocation services directly 
> > or
> > indirectly and find the method to clean up them.
> >
> > Cc more related people.
> >
> > Thanks,
> > Star
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Marvin H?user 
Hey Star,

> I am still curious what is the real issue Marvin met.

There is no issue I met, I simply want to save another call to GetMemoryMap() 
because it may be altered during ExitBS(). It's a break of the specification, 
but it sounds like Intel complying to its own sepcification is not a 
good-enough reason...

Regards,
Marvin.

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Wednesday, June 22, 2016 11:18 AM
> To: Bruce Cran <br...@cran.org.uk>; marvin.haeu...@outlook.com; edk2-
> de...@lists.01.org
> Cc: Tian, Feng <feng.t...@intel.com>
> Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> FreePool() during ExitBS().
> 
> On 2016/6/22 13:39, Bruce Cran wrote:
> > On 6/19/16 9:21 PM, Zeng, Star wrote:
> >
> >> 1. The memory allocate and free in PiSmmCore are SMRAM that is not
> >> related to UEFI memory map.
> >> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
> >> should have got the memory map before ExitBootServices.
> >> That means the memory free should not impact the memory map *got by
> >> UEFI OS loader*, it will only impact the memory map if the UEFI OS
> >> loader will call GetMemoryMap() again.
> >
> >
> > I just found the following post about Linux and how it calls
> > ExitBootServices, which may be relevant:
> >
> > http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBootSer
> > vices-on-failure-td664938.html
> >
> >
> > "ExitBootServices is absolutely supposed to return a failure if any
> > ExitBootServices event handler changes the memory map.  Basically the
> > get_map loop should run again if ExitBootServices returns an error the
> > first time.  I would say it would be fair that if ExitBootServices
> > gives an error the second time then Linux would be fine in returning
> > control back to BIOS."
> >
> 
> Good information that does not assume ExitBootServices event handlers are
> not using memory allocation services.
> In reality, the CoreExitBootServices() in DxeMain.c of EDK2 will never return
> error after calling CoreNotifySignalList ().
> 
> I am still curious what is the real issue Marvin met.
> 
> If we are going to clean up, we may need to review all the ExitBootServices
> event handlers to see if they are using memory allocation services directly or
> indirectly and find the method to clean up them.
> 
> Cc more related people.
> 
> Thanks,
> Star
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Zeng, Star 

Cc Liming and Mike may have some comments.

Thanks,
Star
On 2016/6/22 17:17, Zeng, Star wrote:

On 2016/6/22 13:39, Bruce Cran wrote:

On 6/19/16 9:21 PM, Zeng, Star wrote:


1. The memory allocate and free in PiSmmCore are SMRAM that is not
related to UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
should have got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by
UEFI OS loader*, it will only impact the memory map if the UEFI OS
loader will call GetMemoryMap() again.



I just found the following post about Linux and how it calls
ExitBootServices, which may be relevant:

http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBootServices-on-failure-td664938.html



"ExitBootServices is absolutely supposed to return a failure if any
ExitBootServices event handler changes the memory map.  Basically the
get_map loop should run again if ExitBootServices returns an error the
first time.  I would say it would be fair that if ExitBootServices gives
an error the second time then Linux would be fine in returning control
back to BIOS."



Good information that does not assume ExitBootServices event handlers
are not using memory allocation services.
In reality, the CoreExitBootServices() in DxeMain.c of EDK2 will never
return error after calling CoreNotifySignalList
().

I am still curious what is the real issue Marvin met.

If we are going to clean up, we may need to review all the
ExitBootServices event handlers to see if they are using memory
allocation services directly or indirectly and find the method to clean
up them.

Cc more related people.

Thanks,
Star


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-22 Thread Zeng, Star 

On 2016/6/22 13:39, Bruce Cran wrote:

On 6/19/16 9:21 PM, Zeng, Star wrote:


1. The memory allocate and free in PiSmmCore are SMRAM that is not
related to UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader
should have got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by
UEFI OS loader*, it will only impact the memory map if the UEFI OS
loader will call GetMemoryMap() again.



I just found the following post about Linux and how it calls
ExitBootServices, which may be relevant:

http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBootServices-on-failure-td664938.html


"ExitBootServices is absolutely supposed to return a failure if any
ExitBootServices event handler changes the memory map.  Basically the
get_map loop should run again if ExitBootServices returns an error the
first time.  I would say it would be fair that if ExitBootServices gives
an error the second time then Linux would be fine in returning control
back to BIOS."



Good information that does not assume ExitBootServices event handlers 
are not using memory allocation services.
In reality, the CoreExitBootServices() in DxeMain.c of EDK2 will never 
return error after calling CoreNotifySignalList 
().


I am still curious what is the real issue Marvin met.

If we are going to clean up, we may need to review all the 
ExitBootServices event handlers to see if they are using memory 
allocation services directly or indirectly and find the method to clean 
up them.


Cc more related people.

Thanks,
Star
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-21 Thread Bruce Cran 

On 6/19/16 9:21 PM, Zeng, Star wrote:


1. The memory allocate and free in PiSmmCore are SMRAM that is not related to 
UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have 
got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by UEFI OS 
loader*, it will only impact the memory map if the UEFI OS loader will call 
GetMemoryMap() again.



I just found the following post about Linux and how it calls 
ExitBootServices, which may be relevant:


http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBootServices-on-failure-td664938.html

"ExitBootServices is absolutely supposed to return a failure if any
ExitBootServices event handler changes the memory map.  Basically the
get_map loop should run again if ExitBootServices returns an error the
first time.  I would say it would be fair that if ExitBootServices gives 
an error the second time then Linux would be fine in returning control 
back to BIOS."


--
Bruce
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-20 Thread Andrew Fish 

> On Jun 20, 2016, at 9:10 AM, Bruce Cran  wrote:
> 
> On 6/19/16 9:21 PM, Zeng, Star wrote:
> 
>> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have 
>> got the memory map before ExitBootServices.
>> That means the memory free should not impact the memory map *got by UEFI OS 
>> loader*, it will only impact the memory map if the UEFI OS loader will call 
>> GetMemoryMap() again.
> 
> But aren't boot services supposed to be unavailable during ExitBootServices? 
> So regardless of whether the memory map should or should not be changed, it's 
> possible that gBS is NULL and so it's not possible to call gBS->FreePool?
> 

The Boot Services are not available after ExitBootServices returns.

The Event writer is told to NOT allocate (or Free) memory. 

EVT_SIGNAL_EXIT_BOOT_SERVICES 
This event is to be notified by the system when
ExitBootServices() is invoked. This event is of type EVT_NOTIFY_SIGNAL and 
should not be combined with any other event types. The notification function 
for this event is not allowed to use the Memory Allocation Services, or call 
any functions that use the Memory Allocation Services and must only call 
functions that are known not to use Memory Allocation Services, because these 
services modify the current memory map.The notification function must not 
depend on timer events since timer services will be deactivated before any 
notification functions are called.

The ExitBootServices() caller is told it might happen so code for it. 

The code is here:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L762


In general an ExitBootServices event is not about cleaning up and freeing 
resources. An ExitBootService event exists to to stop hardware. So for example 
you shutdown the DMA engine for the XHCI controller. The memory used for DMA 
buffers is freed back to the caller of ExitBootServices() and the DMA could 
overwrite and OS loader (or OS) allocation. 

Thanks,

Andrew Fish

> -- 
> Bruce
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-20 Thread Marvin H?user 
Hey Bruce,

I think the exact behavior is not defined, though I remember reading (I'm not 
sure if from the specification) that the OS loader should only keep calling 
GetMemoryMap() and ExitBootServices() after the first ExitBootServices() call; 
this would apply to drivers hooking the event as well of course.
Though I think the event was specifically designed to give drivers a chance to 
clean up and I suppose every UEFI implementer will make sure Boot Services are 
not terminated till all events have been trigered. But I might just need to 
re-read that part of the specification.

The primary reason I submited this patch was that the ExitBootServices() is 
more likely to succeed at first, saving the OS loader a call to GetMemoryMap().

Thanks,
Marvin.

> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Monday, June 20, 2016 6:11 PM
> To: Zeng, Star <star.z...@intel.com>; marvin.haeu...@outlook.com; edk2-
> de...@lists.01.org
> Cc: Tian, Feng <feng.t...@intel.com>
> Subject: Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of
> FreePool() during ExitBS().
> 
> On 6/19/16 9:21 PM, Zeng, Star wrote:
> 
> > 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should
> have got the memory map before ExitBootServices.
> > That means the memory free should not impact the memory map *got by
> UEFI OS loader*, it will only impact the memory map if the UEFI OS loader will
> call GetMemoryMap() again.
> 
> But aren't boot services supposed to be unavailable during ExitBootServices?
> So regardless of whether the memory map should or should not be changed,
> it's possible that gBS is NULL and so it's not possible to call gBS->FreePool?
> 
> --
> Bruce
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-20 Thread Marvin Häuser 
Hey Star,

Thanks for your input! I agree, this has been a plain oversight by me.
Would you be fine with a V2 of this patch lacking the modifications to the SMM 
code? There has  been another place this change has been applied to - 
IScsiMisc.c.

Thanks,
Marvin.

> -Original Message-
> From: Zeng, Star [mailto:star.z...@intel.com]
> Sent: Monday, June 20, 2016 5:22 AM
> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: RE: [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool()
> during ExitBS().
> 
> Hi Marvin,
> 
> 1. The memory allocate and free in PiSmmCore are SMRAM that is not
> related to UEFI memory map.
> 2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have
> got the memory map before ExitBootServices.
> That means the memory free should not impact the memory map *got by
> UEFI OS loader*, it will only impact the memory map if the UEFI OS loader will
> call GetMemoryMap() again.
> 
> "A UEFI OS loader must ensure that it has the system's current memory map
> at the time it calls ExitBootServices(). This is done by passing in the 
> current
> memory map's MapKey value as returned by
> EFI_BOOT_SERVICES.GetMemoryMap()."
> 
> Thanks,
> Star
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Monday, June 20, 2016 1:08 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Zeng, Star 
> Subject: [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool()
> during ExitBS().
> 
> During exiting Boot Services, there should be no changes made to the
> Memory Map. This patch eliminates calls to FreePool() and
> CloseEvent() (which calls FreePool()) and instead zero's the memory.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Marvin Haeuser 
> ---
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c |  2 +-
>  MdeModulePkg/Core/PiSmmCore/Smi.c   | 41
> +---
>  MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c |  6 ++-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 17 
>  4 files changed, 57 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> index 7245f201fbdf..96e8da02bbc6 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> @@ -204,7 +204,7 @@ SmmExitBootServicesHandler (
>   NULL
>   );
> 
> -  SmiHandlerUnRegister (DispatchHandle);
> +  SmiHandlerUnRegisterWorker (DispatchHandle, TRUE);
> 
>return Status;
>  }
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index 816d0f519360..a22606517f37 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -280,9 +280,10 @@ SmiHandlerRegister (  }
> 
>  /**
> -  Unregister a handler in SMM.
> +  Internal worker function to unregister a handler in SMM.
> 
> -  @param  DispatchHandle  The handle that was specified when the handler
> was registered.
> +  @param  DispatchHandleThe handle that was specified when the
> handler was registered.
> +  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in
> progress.
> 
>@retval EFI_SUCCESS   Handler function was successfully 
> unregistered.
>@retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid
> handle.
> @@ -290,8 +291,9 @@ SmiHandlerRegister (  **/  EFI_STATUS  EFIAPI -
> SmiHandlerUnRegister (
> -  IN EFI_HANDLE  DispatchHandle
> +SmiHandlerUnRegisterWorker (
> +  IN  EFI_HANDLE  DispatchHandle,
> +  IN  BOOLEAN ExitBootServices
>)
>  {
>SMI_HANDLER  *SmiHandler;
> @@ -310,7 +312,12 @@ SmiHandlerUnRegister (
>SmiEntry = SmiHandler->SmiEntry;
> 
>RemoveEntryList (>Link);
> -  FreePool (SmiHandler);
> +
> +  if (!ExitBootServices) {
> +FreePool (SmiHandler);
> +  } else {
> +ZeroMem (SmiHandler, sizeof (*SmiHandler));  }
> 
>if (SmiEntry == NULL) {
>  //
> @@ -325,8 +332,30 @@ SmiHandlerUnRegister (
>  //
>  RemoveEntryList (>AllEntries);
> 
> -FreePool (SmiEntry);
> +if (!ExitBootServices) {
> +  FreePool (SmiEntry);
> +} else {
> +  ZeroMem (SmiEntry, sizeof (*SmiEntry));
> +}
>}
> 
>return EFI_SUCCESS;
>  }
> +
> +/**
> +  Unregister a handler in SMM.
> +
> +  @param  DispatchHandle  The handle that was specified when the handler
> was registered.
> +
> +  @retval EFI_SUCCESS   Handler function was successfully 
> unregistered.
> +  @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a
> valid handle.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +SmiHandlerUnRegister (
> +  IN EFI_HANDLE  DispatchHandle
> +  )
> +{
> +  return SmiHandlerUnRegisterWorker (DispatchHandle, FALSE); }
> diff --git

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-20 Thread Bruce Cran 

On 6/19/16 9:21 PM, Zeng, Star wrote:


2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have 
got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by UEFI OS 
loader*, it will only impact the memory map if the UEFI OS loader will call 
GetMemoryMap() again.


But aren't boot services supposed to be unavailable during 
ExitBootServices? So regardless of whether the memory map should or 
should not be changed, it's possible that gBS is NULL and so it's not 
possible to call gBS->FreePool?


--
Bruce
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-19 Thread Zeng, Star 
Hi Marvin,

1. The memory allocate and free in PiSmmCore are SMRAM that is not related to 
UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have 
got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by UEFI OS 
loader*, it will only impact the memory map if the UEFI OS loader will call 
GetMemoryMap() again.

"A UEFI OS loader must ensure that it has the system's current memory map at 
the time it calls
ExitBootServices(). This is done by passing in the current memory map's MapKey 
value as
returned by EFI_BOOT_SERVICES.GetMemoryMap()."

Thanks,
Star
-Original Message-
From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] 
Sent: Monday, June 20, 2016 1:08 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star 
Subject: [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during 
ExitBS().

During exiting Boot Services, there should be no changes made to the Memory 
Map. This patch eliminates calls to FreePool() and
CloseEvent() (which calls FreePool()) and instead zero's the memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c |  2 +-
 MdeModulePkg/Core/PiSmmCore/Smi.c   | 41 +---
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c |  6 ++-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 17 
 4 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 7245f201fbdf..96e8da02bbc6 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -204,7 +204,7 @@ SmmExitBootServicesHandler (
  NULL
  );
 
-  SmiHandlerUnRegister (DispatchHandle);
+  SmiHandlerUnRegisterWorker (DispatchHandle, TRUE);
 
   return Status;
 }
diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c 
b/MdeModulePkg/Core/PiSmmCore/Smi.c
index 816d0f519360..a22606517f37 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -280,9 +280,10 @@ SmiHandlerRegister (  }
 
 /**
-  Unregister a handler in SMM.
+  Internal worker function to unregister a handler in SMM.
 
-  @param  DispatchHandle  The handle that was specified when the handler was 
registered.
+  @param  DispatchHandleThe handle that was specified when the handler was 
registered.
+  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in 
progress.
 
   @retval EFI_SUCCESS   Handler function was successfully unregistered.
   @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
@@ -290,8 +291,9 @@ SmiHandlerRegister (  **/  EFI_STATUS  EFIAPI 
-SmiHandlerUnRegister (
-  IN EFI_HANDLE  DispatchHandle
+SmiHandlerUnRegisterWorker (
+  IN  EFI_HANDLE  DispatchHandle,
+  IN  BOOLEAN ExitBootServices
   )
 {
   SMI_HANDLER  *SmiHandler;
@@ -310,7 +312,12 @@ SmiHandlerUnRegister (
   SmiEntry = SmiHandler->SmiEntry;
 
   RemoveEntryList (>Link);
-  FreePool (SmiHandler);
+
+  if (!ExitBootServices) {
+FreePool (SmiHandler);
+  } else {
+ZeroMem (SmiHandler, sizeof (*SmiHandler));  }
 
   if (SmiEntry == NULL) {
 //
@@ -325,8 +332,30 @@ SmiHandlerUnRegister (
 //
 RemoveEntryList (>AllEntries);
 
-FreePool (SmiEntry);
+if (!ExitBootServices) {
+  FreePool (SmiEntry);
+} else {
+  ZeroMem (SmiEntry, sizeof (*SmiEntry));
+}
   }
 
   return EFI_SUCCESS;
 }
+
+/**
+  Unregister a handler in SMM.
+
+  @param  DispatchHandle  The handle that was specified when the handler was 
registered.
+
+  @retval EFI_SUCCESS   Handler function was successfully unregistered.
+  @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
+
+**/
+EFI_STATUS
+EFIAPI
+SmiHandlerUnRegister (
+  IN EFI_HANDLE  DispatchHandle
+  )
+{
+  return SmiHandlerUnRegisterWorker (DispatchHandle, FALSE); }
diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
index ae202c3fe24a..a5a7368c8d39 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
@@ -872,9 +872,11 @@ IScsiOnExitBootService (
   ISCSI_DRIVER_DATA *Private;
 
   Private = (ISCSI_DRIVER_DATA *) Context;
-  gBS->CloseEvent (Private->ExitBootServiceEvent);
 
-  IScsiSessionAbort (>Session);
+  if (Private->Session.Signature != 0) {
+IScsiSessionAbort (>Session);
+ZeroMem (>Session, sizeof (Private->Session));  }
 }
 
 /**
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index 0e9c92abef9a..787786bfba9f 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -593,6 +593,23 @@

[edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

2016-06-19 Thread Marvin Häuser 
During exiting Boot Services, there should be no changes made to the
Memory Map. This patch eliminates calls to FreePool() and
CloseEvent() (which calls FreePool()) and instead zero's the memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c |  2 +-
 MdeModulePkg/Core/PiSmmCore/Smi.c   | 41 +---
 MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c |  6 ++-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 17 
 4 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
index 7245f201fbdf..96e8da02bbc6 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
@@ -204,7 +204,7 @@ SmmExitBootServicesHandler (
  NULL
  );
 
-  SmiHandlerUnRegister (DispatchHandle);
+  SmiHandlerUnRegisterWorker (DispatchHandle, TRUE);
 
   return Status;
 }
diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c 
b/MdeModulePkg/Core/PiSmmCore/Smi.c
index 816d0f519360..a22606517f37 100644
--- a/MdeModulePkg/Core/PiSmmCore/Smi.c
+++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
@@ -280,9 +280,10 @@ SmiHandlerRegister (
 }
 
 /**
-  Unregister a handler in SMM.
+  Internal worker function to unregister a handler in SMM.
 
-  @param  DispatchHandle  The handle that was specified when the handler was 
registered.
+  @param  DispatchHandleThe handle that was specified when the handler was 
registered.
+  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in 
progress.
 
   @retval EFI_SUCCESS   Handler function was successfully unregistered.
   @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
@@ -290,8 +291,9 @@ SmiHandlerRegister (
 **/
 EFI_STATUS
 EFIAPI
-SmiHandlerUnRegister (
-  IN EFI_HANDLE  DispatchHandle
+SmiHandlerUnRegisterWorker (
+  IN  EFI_HANDLE  DispatchHandle,
+  IN  BOOLEAN ExitBootServices
   )
 {
   SMI_HANDLER  *SmiHandler;
@@ -310,7 +312,12 @@ SmiHandlerUnRegister (
   SmiEntry = SmiHandler->SmiEntry;
 
   RemoveEntryList (>Link);
-  FreePool (SmiHandler);
+
+  if (!ExitBootServices) {
+FreePool (SmiHandler);
+  } else {
+ZeroMem (SmiHandler, sizeof (*SmiHandler));
+  }
 
   if (SmiEntry == NULL) {
 //
@@ -325,8 +332,30 @@ SmiHandlerUnRegister (
 //
 RemoveEntryList (>AllEntries);
 
-FreePool (SmiEntry);
+if (!ExitBootServices) {
+  FreePool (SmiEntry);
+} else {
+  ZeroMem (SmiEntry, sizeof (*SmiEntry));
+}
   }
 
   return EFI_SUCCESS;
 }
+
+/**
+  Unregister a handler in SMM.
+
+  @param  DispatchHandle  The handle that was specified when the handler was 
registered.
+
+  @retval EFI_SUCCESS   Handler function was successfully unregistered.
+  @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
+
+**/
+EFI_STATUS
+EFIAPI
+SmiHandlerUnRegister (
+  IN EFI_HANDLE  DispatchHandle
+  )
+{
+  return SmiHandlerUnRegisterWorker (DispatchHandle, FALSE);
+}
diff --git a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c 
b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
index ae202c3fe24a..a5a7368c8d39 100644
--- a/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
+++ b/MdeModulePkg/Universal/Network/IScsiDxe/IScsiMisc.c
@@ -872,9 +872,11 @@ IScsiOnExitBootService (
   ISCSI_DRIVER_DATA *Private;
 
   Private = (ISCSI_DRIVER_DATA *) Context;
-  gBS->CloseEvent (Private->ExitBootServiceEvent);
 
-  IScsiSessionAbort (>Session);
+  if (Private->Session.Signature != 0) {
+IScsiSessionAbort (>Session);
+ZeroMem (>Session, sizeof (Private->Session));
+  }
 }
 
 /**
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
index 0e9c92abef9a..787786bfba9f 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -593,6 +593,23 @@ SmiHandlerRegister (
   );
 
 /**
+  Internal worker function to unregister a handler in SMM.
+
+  @param  DispatchHandleThe handle that was specified when the handler was 
registered.
+  @param  ExitBootServices  Indicates whether or not ExitBootServices() is in 
progress.
+
+  @retval EFI_SUCCESS   Handler function was successfully unregistered.
+  @retval EFI_INVALID_PARAMETER DispatchHandle does not refer to a valid 
handle.
+
+**/
+EFI_STATUS
+EFIAPI
+SmiHandlerUnRegisterWorker (
+  IN  EFI_HANDLE  DispatchHandle,
+  IN  BOOLEAN ExitBootServices
+  );
+
+/**
   Unregister a handler in SMM.
 
   @param  DispatchHandle  The handle that was specified when the handler was 
registered.
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel