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>
---
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",
+ .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",
+ .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
}
};
--
2.46.1
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) Perhaps s/ghes/hest/ > + .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 > } > };
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
© 2016 - 2024 Red Hat, Inc.