[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240925062600.7cbfeb19@foz.lan>
Date: Wed, 25 Sep 2024 06:26:00 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Igor Mammedov <imammedo@...hat.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Shiju Jose
<shiju.jose@...wei.com>, "Michael S. Tsirkin" <mst@...hat.com>, Ani Sinha
<anisinha@...hat.com>, Cleber Rosa <crosa@...hat.com>, Dongjiu Geng
<gengdongjiu1@...il.com>, Eric Blake <eblake@...hat.com>, John Snow
<jsnow@...hat.com>, Markus Armbruster <armbru@...hat.com>, Michael Roth
<michael.roth@....com>, Paolo Bonzini <pbonzini@...hat.com>, Peter Maydell
<peter.maydell@...aro.org>, Shannon Zhao <shannon.zhaosl@...il.com>,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org, qemu-arm@...gnu.org,
qemu-devel@...gnu.org
Subject: Re: [PATCH v10 00/21] Add ACPI CPER firmware first error injection
on ARM emulation
Em Tue, 24 Sep 2024 15:14:29 +0200
Igor Mammedov <imammedo@...hat.com> escreveu:
> > 1) preparation patches:
...
> > 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
Ok.
> > 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
>
Ok, sent a PR with the first set (cleanups) at:
https://lore.kernel.org/qemu-devel/cover.1727236561.git.mchehab+huawei@kernel.org/
You can see the full series at:
https://gitlab.com/mchehab_kernel/qemu/-/commits/qemu_submission_v11b?ref_type=heads
It works fine, except for the migration part that I'm still working with.
For the migration, there are how two functions at ghes.c:
The one compatible with current behavior (up to version 9.1):
https://gitlab.com/mchehab_kernel/qemu/-/blob/qemu_submission_v11b/hw/acpi/ghes.c?ref_type=heads#L411
And the new one using offsets calculated from HEST (newer versions):
https://gitlab.com/mchehab_kernel/qemu/-/blob/qemu_submission_v11b/hw/acpi/ghes.c?ref_type=heads#L437
With that, the migration logic can decide what function should be
called (currently, it is just checking if hest_addr_le is zero, but
I guess I'll need to change it to match some variable added by the
migration path.
Also, in preparation for the migration tests, I created a separate
branch at:
https://gitlab.com/mchehab_kernel/qemu/-/commits/ghes_on_v9.1.0?ref_type=heads
which contains the same patches on the top of 9.1, except for
the HEST ones. It also contains a hack to use ACPI_GHES_NOTIFY_GPIO
instead of ACPI_GHES_NOTIFY_SEA.
With that, we have a way to use the same error injection logic
on both 9.1 and upstream, hopefully being enough to test if migration
works.
Thanks,
Mauro
Powered by blists - more mailing lists