Re: [edk2-devel] [PATCH resend] MdeModulePkg/EsrtDxe: allocate ESRT table from RtServicesData memory

["Michael D Kinney" <michael.d.kinney@intel.com>]

Ard,

Saw your patch to cache the GUID table.  The ESRT Table
is not that much bigger, so the algorithm may be simpler
if you just make a copy of the ESRT table with the 
active entries. 

* 16+24 bytes per ESRT entry.
* 16 bytes/entry for just the GUID.

The only advantage of checking against the ESRT GUID at
RT is to reject capsules that will be rejected when the
capsule is processed later.  This can prevent extra reboots
if an OS agent is sending capsules that do not really 
apply to the current system.  I expect OS agent to only 
send capsules that are in the ESRT.

Mike

> -----Original Message-----
> From: Kinney, Michael D
> Sent: Friday, April 19, 2019 12:46 PM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Kinney,
> Michael D <michael.d.kinney@intel.com>
> Cc: devel@edk2.groups.io; ming.huang@linaro.org; Wu,
> Hao A <hao.a.wu@intel.com>; Wang, Jian J
> <jian.j.wang@intel.com>
> Subject: RE: [edk2-devel] [PATCH resend]
> MdeModulePkg/EsrtDxe: allocate ESRT table from
> RtServicesData memory
> 
> 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.biesheuvel@linaro.org]
> > Sent: Friday, April 19, 2019 11:43 AM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>
> > Cc: devel@edk2.groups.io; ming.huang@linaro.org; Wu,
> > Hao A <hao.a.wu@intel.com>; Wang, Jian J
> > <jian.j.wang@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.biesheuvel@linaro.org> wrote:
> > >
> > > On Fri, 19 Apr 2019 at 20:23, Kinney, Michael D
> > > <michael.d.kinney@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.