On Tue, 24 Sep 2024 15:00:58 +0200 Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > 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 this one doesn't belong to clean ups, I think. Lets move this to #3 part > > 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? other than nit above, LGTM > > Thanks, > Mauro >
