[Skiboot] [RFC PATCH v5 09/16] hdata/memory.c: Parse HDAT for secure memory

Ryan Grimm grimm at linux.vnet.ibm.com
Tue Mar 31 03:22:33 AEDT 2020


On Tue, 2020-03-24 at 10:14 +1100, Oliver O'Halloran wrote:
>               /*
> > >                * Workaround broken HDAT reserve regions which are
> > > -              * bigger than 512MB
> > > +              * bigger than 512MB and not secure memory
> > >                */
> > > -             if ((end_addr - start_addr) > 0x20000000) {
> > > +             if (((end_addr - start_addr) > 0x20000000) &&
> > > +                     !(start_addr & UV_SECURE_MEM_BIT)) {
> > 
> > 
> > Is this a hostboot bug? Where does this broken HDAT come from and
> > can we
> > fix it there?
> 
> It was a hostboot bug that turned up some time early in p9 bringup
> that never seemed to get fixed so I worked around it instead. Maybe
> it's been fixed by now, but honestly I don't really care.
> 
> > Anyway this bit seems unrelated to the other half of the
> > patch about "secure-memory".
> 
> I think it's a carry over from earlier versions of this patchset
> which
> put the secure memory ranges into /reserved-memory/ rather than
> having
> actual memory nodes. I don't think there's any real need to support
> giant reservations in secure memory so this should probably be
> dropped.
> 

OK, I thought we needed this but I was reading the workaround
incorrectly.  I thought it was to workaround regions with starting
address beyond 512MB but it's working around regions bigger than 512MB.

FYI HB reserves in secure memory are within a 64MB now, not sure how
official that value is.

So, yeah, this will be dropped.

-Ryan

> > >                       prlog(PR_ERR, "MEM: Ignoring Bad HDAT
> > > reserve: too big\n");
> > >                       continue;
> > >               }
> > > 
> > 
> > --
> > Alexey



More information about the Skiboot mailing list