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: > > > > > > 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-Exi > > > > > > tBoo > > > > > > 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 > > > (&gEfiEventExitBootServicesGuid). > > > > > > > > > > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
