Em Thu, 26 Sep 2024 13:03:48 +0100 Jonathan Cameron <jonathan.came...@huawei.com> escreveu:
> On Wed, 25 Sep 2024 06:04:15 +0200 > Mauro Carvalho Chehab <mchehab+hua...@kernel.org> wrote: > > > Currently, CPER address location is calculated as an offset of > > the hardware_errors table. It is also badly named, as the > > offset actually used is the address where the CPER data starts, > > and not the beginning of the error source. > > > > Move the logic which calculates such offset to a separate > > function, in preparation for a patch that will be changing the > > logic to calculate it from the HEST table. > > > > While here, properly name the variable which stores the cper > > address. > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+hua...@kernel.org> > Trivial comment inline. > > Given this is a placeholder for more radical refactor I'll not comment on > the maths etc being less flexible than it will hopefully end up! Actually there will be two versions of the math calculus after the next patch series: 1. one compatible with versions up to 9.1 that work with a single source ID, using offsets calculated from the hardware_errors table, which doesn't contain the number of sources. Such code will be used only for migration. This is the one on this series; 2. one that will get the number of source IDs from the HEST table. Such math will be added at the next patch series. This requires a migration-incompatible change to store a pointer to HEST table. The math there is flexible and should work with all future changes, as it uses all offsets from the HEST table, using the links there to the harware_errors firmware file. So, basically, the migration logic will check if a HEST pointer is stored. If so, it will use (2). If not, it is because the VM that was running on QEMU 9.1 had its state stored, and then was recovered on QEMU 9.2. Such machine will then use the math from (1), which supports a single source ID. Thanks, Mauro
