From: Peter Xu <peterx@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Shiju Jose <shiju.jose@huawei.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ani Sinha <anisinha@redhat.com>,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [PATCH RFC 3/5] acpi/generic_event_device: Update GHES migration to cover hest addr
Date: Wed, 2 Oct 2024 11:46:31 -0400 [thread overview]
Message-ID: <Zv1q141LZt59SDSM@x1n> (raw)
In-Reply-To: <20241002171543.703ab6e1@imammedo.users.ipa.redhat.com>
On Wed, Oct 02, 2024 at 05:15:43PM +0200, Igor Mammedov wrote:
> On Tue, 1 Oct 2024 13:42:48 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > The GHES migration logic at GED should now support HEST table
> > location too.
> >
> > Increase migration version and change needed to check for both
> > ghes_addr_le and hest_addr_le.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>
> other than minor issues below, lgtm
>
> > ---
> > hw/acpi/generic_event_device.c | 29 +++++++++++++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> > index d4dbfb45e181..49ca1fb8e84a 100644
> > --- a/hw/acpi/generic_event_device.c
> > +++ b/hw/acpi/generic_event_device.c
> > @@ -369,6 +369,34 @@ static const VMStateDescription vmstate_ghes_state = {
> > }
> > };
> >
> > +static const VMStateDescription vmstate_hest = {
> > + .name = "acpi-ghes",
> duplicate name for section, we use that already for hw_error address
> I don't know ramification of (CCIng Peter)
Currently the existing vmstate_ghes is embeded inside vmstate_ghes_state,
so maybe.. it's ok, as I remember QEMU only registers top level vmsds (via
vmstate_register_with_alias_id()).
We do have a sanity check in savevm_state_handler_insert() making sure no
duplicated entry will co-exist since commit caa91b3c44cd.
>
> Perhaps
> s/ghes/hest/
Said that, perhaps it'll still be nice to try avoiding same names indeed if
possible, at least it could make debugging / reading easier sometimes.
>
>
>
> > + .version_id = 1,
> > + .minimum_version_id = 1,
> > + .fields = (const VMStateField[]) {
> > + VMSTATE_UINT64(hest_addr_le, AcpiGhesState),
> > + VMSTATE_END_OF_LIST()
> > + },
> > +};
> > +
> > +static bool hest_needed(void *opaque)
> > +{
> > + AcpiGedState *s = opaque;
> > + return s->ghes_state.hest_addr_le;
> > +}
> > +
> > +static const VMStateDescription vmstate_hest_state = {
> > + .name = "acpi-ged/ghes",
>
> ditto
>
> > + .version_id = 1,
> > + .minimum_version_id = 1,
> > + .needed = hest_needed,
> > + .fields = (const VMStateField[]) {
> > + VMSTATE_STRUCT(ghes_state, AcpiGedState, 1,
> > + vmstate_hest, AcpiGhesState),
> > + VMSTATE_END_OF_LIST()
> > + }
> > +};
> > +
> > static const VMStateDescription vmstate_acpi_ged = {
> > .name = "acpi-ged",
> > .version_id = 1,
> > @@ -380,6 +408,7 @@ static const VMStateDescription vmstate_acpi_ged = {
> > .subsections = (const VMStateDescription * const []) {
> > &vmstate_memhp_state,
> > &vmstate_ghes_state,
> > + &vmstate_hest_state,
> > NULL
> > }
> > };
>
--
Peter Xu
next prev parent reply other threads:[~2024-10-02 15:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 11:42 [PATCH RFC 0/5] Change ghes driver to use HEST-based offsets Mauro Carvalho Chehab
2024-10-01 11:42 ` [PATCH RFC 1/5] acpi/ghes: add a firmware file with HEST address Mauro Carvalho Chehab
2024-10-01 11:42 ` [PATCH RFC 2/5] acpi/ghes: Use HEST table offsets when preparing GHES records Mauro Carvalho Chehab
2024-10-02 14:25 ` Igor Mammedov
2024-10-01 11:42 ` [PATCH RFC 3/5] acpi/generic_event_device: Update GHES migration to cover hest addr Mauro Carvalho Chehab
2024-10-02 15:15 ` Igor Mammedov
2024-10-02 15:46 ` Peter Xu [this message]
2024-10-01 11:42 ` [PATCH RFC 4/5] acpi/generic_event_device: add logic to detect if HEST addr is available Mauro Carvalho Chehab
2024-10-03 14:27 ` Igor Mammedov
2024-11-12 14:55 ` Mauro Carvalho Chehab
2024-11-12 15:22 ` Mauro Carvalho Chehab
2024-10-01 11:42 ` [PATCH RFC 5/5] arm/virt-acpi-build: Properly handle virt-9.1 Mauro Carvalho Chehab
2024-10-03 14:46 ` Igor Mammedov
2024-10-02 13:45 ` [PATCH RFC 0/5] Change ghes driver to use HEST-based offsets Igor Mammedov
2024-11-13 6:54 ` Mauro Carvalho Chehab
2024-11-13 6:57 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zv1q141LZt59SDSM@x1n \
--to=peterx@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=anisinha@redhat.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shiju.jose@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.