Em Tue, 17 Sep 2024 14:15:19 +0200 Igor Mammedov <imammedo@xxxxxxxxxx> escreveu: > I'm done with this round of review. > > Given that the series accumulated a bunch of cleanups, > I'd suggest to move all cleanups/renamings not related > to new HEST lookup and new src id mapping to the beginning > of the series, so once they reviewed they could be split up into > a separate series that could be merged while we are ironing down > the new functionality. I've rebased the series placing the preparation stuff (cleanups and renames) at the beginning. So, what I have now is: 1) preparation patches: 41709f0898e1 acpi/ghes: get rid of ACPI_HEST_SRC_ID_RESERVED 5409daa41c78 acpi/ghes: simplify acpi_ghes_record_errors() code 2539f1f662b9 acpi/ghes: better handle source_id and notification 3f19400549c1 acpi/ghes: Remove a duplicated out of bounds check f0b06ecede46 acpi/ghes: Change the type for source_id 9f08301ac195 acpi/ghes: Prepare to support multiple sources on ghes 2426cd76e868 acpi/ghes: make the GHES record generation more generic 3fb7ec864700 acpi/ghes: better name GHES memory error function 1a22dad3211e acpi/ghes: don't crash QEMU if ghes GED is not found 726968d4ee20 acpi/ghes: rename etc/hardware_error file macros f562380da7ce docs: acpi_hest_ghes: fix documentation for CPER size 69850f550f99 acpi/generic_event_device: add an APEI error device Patches were changed to ensure that they won't be add any new new features. They are just code shift in order to make the diff of the next patches smaller. There is a small point here: the logic was simplified to only support a single source ID (I added an assert() to enforce it) and simplified the calculus in preparation for the HEST and migration series. 2) add a BIOS pointer to HEST, using it. The migration stuff will be along those: c24f1a8708e3 acpi/ghes: add a firmware file with HEST address 853dce23ec39 acpi/ghes: Use HEST table offsets when preparing GHES records c148716fd7c8 acpi/generic_event_device: Update GHES migration to cover hest addr Up to that, still no new features, but the offset calculus will be relative to HEST table and will use the bios pointers stored there; 3) Add support for generic error inject: f5ec0d197d82 acpi/ghes: add a notifier to notify when error data is ready f5e015537209 arm/virt: Wire up a GED error device for ACPI / GHES 3b6692dbf473 qapi/acpi-hest: add an interface to do generic CPER error injection 620a5a49f218 scripts/ghes_inject: add a script to generate GHES error inject 4) MPIDR property: 2dd6e3aae450 target/arm: add an experimental mpidr arm cpu property object 02c88cd4daa2 scripts/arm_processor_error.py: retrieve mpidr if not filled I'm still testing if the rebase didn't cause any issues. So, the above may still change a little bit. I also need to address your comments to the cleanup patches and work at the migration, but just want to double check if this is what you want. If OK to you, my plan is to submit you the cleanup patches after I finish testing the hole series. The migration logic will require some time, and I don't want to bother with the cleanup stuff while doing it. So, perhaps while I'm doing it, you could review/merge the cleanups. We can do the same for each of the 4 above series of patches, as it makes review simpler as there will be less patches to look into on each series. Would it work for you? Thanks, Mauro
