[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