On Wed, 7 Aug 2024 10:34:36 +0100 Jonathan Cameron <jonathan.came...@huawei.com> wrote:
> On Wed, 7 Aug 2024 09:47:50 +0200 > Mauro Carvalho Chehab <mchehab+hua...@kernel.org> wrote: > > > Em Tue, 6 Aug 2024 16:31:13 +0200 > > Igor Mammedov <imamm...@redhat.com> escreveu: > > > > > PS: > > > looking at the code, ACPI_GHES_MAX_RAW_DATA_LENGTH is 1K > > > and it is the total size of a error block for a error source. > > > > > > However acpi_hest_ghes.rst (3) says it should be 4K, > > > am I mistaken? > > > > Maybe Jonathan knows better, but I guess the 1K was just some > > arbitrary limit to prevent a too big CPER. The 4K limit described > > at acpi_hest_ghes.rst could be just some limit to cope with > > the current bios implementation, but I didn't check myself how > > this is implemented there. > > > > I was unable to find any limit at the specs. Yet, if you look at: > > > > https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section > > > > I think both limits are just made up. You can in theory log huge > error records. Just not one does. What I care about is what we actually allocate vs what we promised in docs. Given that it's harder to change actual size (we would need a compat handling here not to break old machine types), I would vote for syncing docs to match code. A separate stand-alone patch for fixing it would do, or it could be a part of series. Also I'd like another pair of eyes to look at it to confirm actual size we allocate, in case I'm not seeing it right. > > The processor Error Information Structure, starting at offset > > 40, can go up to 255*32, meaning an offset of 8200, which is > > bigger than 4K. > > > > Going further, processor context can have up to 65535 (spec > > actually says 65536, but that sounds a typo, as the size is > > stored on an uint16_t), containing multiple register values > > there (the spec calls its length as "P"). > > > > So, the CPER record could, in theory, have: > > 8200 + (65535 * P) + sizeof(vendor-specicific-info) > > > > The CPER length is stored in Section Length record, which is > > uint32_t. > > > > So, I'd say that the GHES record can theoretically be a lot > > bigger than 4K. > Agreed - but I don't think we care for testing as long as it's > big enough for plausible records. Unless you really want > to fuzz the limits? > > Jonathan > > > > > Thanks, > > Mauro >
