On Thu, Apr 01, 2021 at 05:44:06PM +0300, Mike Banon wrote: > Good day Kevin, please tell if there's anything I can add for us to > proceed with a review of this patch. > > On Tue, Mar 9, 2021 at 12:54 PM Mike Banon <mikeb...@gmail.com> wrote: > > > > According to my calculations, my proposed 768 default - which is just > > slightly larger than a previous 600 - should also allow having ~20 > > CPUs, although the systems with 20 CPUs are significantly less popular > > than i.e. 16. Also, the uneven (unrelated to the power of 2's) values > > of 600 weren't really justified in the first place: 768 decimal is > > 0x300, while 600 is a weird 0x258. > > > > On Tue, Mar 9, 2021 at 2:28 AM Kevin O'Connor <ke...@koconnor.net> wrote: > > > > > > On Tue, Mar 02, 2021 at 11:21:27PM +0300, Mike Banon wrote: > > > > There are plenty of coreboot platforms whose MPTABLE size is just > > > > slightly larger than the current uneven limit of 600 bytes, which > > > > prevents these important tables from being copied. For example, G505S > > > > has 628 bytes and A88XM-E has 740 bytes. I propose 768 bytes as a new > > > > saner default for MPTABLE size, to replace the current uneven limit of > > > > 600. SMBIOS size should be bumped the similar way as well. > > > > > > This doesn't look correct to me. There is only a limited amount of > > > space in the f-segment, and it shouldn't be necessary to store large > > > tables there. All recent OSes should support the SMBIOS in > > > high-memory, and recent OSes don't need the mptable at all. > > > > > > The concern with increasing the size is that it could cause allocation > > > failures for other critical information that does need to be stored in > > > the f-segment (like drive layout). > > > > > > -Kevin
I don't agree with the patch due to the reasons described above. -Kevin _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
