Be honest, I am not clear about the history why EfiBootServicesData is required for ESRT. But OS indeed cares about ESRT table, for example, I guess the Firmware in Device Manager for Windows is built based on ESRT table. In fact, I think OS loader can access either EfiBootServicesData or EfiRuntimeServicesData configuration table as it controls the runtime phase point.
I am concerning that even the spec could be updated, our code may still need caching for backward compatibility. Thanks, Star -----Original Message----- From: Ard Biesheuvel [mailto:[email protected]] Sent: Friday, October 19, 2018 1:11 PM To: Zeng, Star <[email protected]> Cc: Peter Jones <[email protected]>; [email protected]; Dong, Eric <[email protected]>; Leif Lindholm <[email protected]>; Kinney, Michael D <[email protected]>; Yao, Jiewen <[email protected]> Subject: Re: [PATCH] MdeModulePkg/EsrtDxe: allocate ESRT table from RtServicesData memory On 19 October 2018 at 13:01, Ard Biesheuvel <[email protected]> wrote: > On 19 October 2018 at 12:48, Zeng, Star <[email protected]> wrote: >> Ok, thanks and got the case. >> >> DxeCapsuleLibVirtualAddressChangeEvent may be too late as it could not >> allocate pool to do caching. >> I meant registering gEfiSystemResourceTableGuid event group >> notification(installconfigurationtable will trigger event group) and do >> caching in the notification function. >> >> > > OK, I will create a bugzilla for this. > As I understand it, the reason we require EfiBootServicesData for the ESRT is because the OS may not care about this table, and so we don't want to waste the memory. However, if we end up caching the entire table in EfiRuntimeServicesData anyway [so that the firmware itself can access it], is there still a point to keeping this requirement? Shouldn't we update the spec regardless? _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
