Ard, I think skipping the nested check at runtime is a good idea. No need for ESRT at RT and no need to cache GUIDs at EBS.
Mike > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, April 19, 2019 11:43 AM > To: Kinney, Michael D <michael.d.kin...@intel.com> > Cc: devel@edk2.groups.io; ming.hu...@linaro.org; Wu, > Hao A <hao.a...@intel.com>; Wang, Jian J > <jian.j.w...@intel.com> > Subject: Re: [edk2-devel] [PATCH resend] > MdeModulePkg/EsrtDxe: allocate ESRT table from > RtServicesData memory > > On Fri, 19 Apr 2019 at 20:38, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: > > > > On Fri, 19 Apr 2019 at 20:23, Kinney, Michael D > > <michael.d.kin...@intel.com> wrote: > > > > > > Ard, > > > > > > Let's see if we can remove the ESRT access from > those > > > paths. That would be the better fix. > > > > > > > I am not that familiar with this code, but it seems > that the only > > reason we access the ESRT at runtime is to check > whether a capsule is > > a nested FMP capsule, where the outer GUID is cross > referenced against > > the ESRT before checking whether the inner GUID is > the FMP guid. > > > > Could we relax this check? FMP capsule can only be > dispatched across a > > reboot anyway, and so the runtime capsule handling > could accept any > > capsule that has an inner FMP guid. > > > > If not, it means we do need to read the ESRT at > runtime, in which case > > my patch is the simplest solution. We would have to > clarify the spec > > though. > > > > Actually, I might be able to cache just the list of > GUIDs at > ReadyToBoot, so we can do the comparisons at runtime. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#39336): https://edk2.groups.io/g/devel/message/39336 Mute This Topic: https://groups.io/mt/31245843/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
