> > Probably just nobody expected that big hobs being ever needed when this > was designed looooong ago. > > But as laszlo outlined: There is the option to use a page allocation > for the array and store a pointer to the array in the HOB. Which is > probably the simplest approach given you have a single, linear array > then. >
Pointer is not the right direction usage in the HOB, it will still bring the complexity in standalone MM part. Because we need duplicate the same hobs for Standalone MM usage, if the hobs contains the point, it will bring another steps to allocate the buffer again for SMM usage. > > For smbase case: I doubt CpuIndex is really required, because we can't > > avoid define another hob, and we can't avoid add statement for each > > hob cpu ranges (0 - 8191, 8192 - 16382,...), then what's meaning for > > the CpuIndex, we don't expect hob producer create smaller granularity > > CPU ranges that one hob CpuIndex associate with previous NumberOfCpus. > > With multiple HOBs the consumer needs to know which HOB covers which CPU > range. So in addition to the number of cpus covered by the HOB you also > need to know what the first CPU is. > I original thought that we can fix the CPU ranges for each CPU hob, but it does need define the new hob guid again and again. Well, one hob guid with cpuindex is fine. > take care, > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99420): https://edk2.groups.io/g/devel/message/99420 Mute This Topic: https://groups.io/mt/96350760/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
