Create a new property (x-has-hest-addr) and use it to detect if
the GHES table offsets can be calculated from the HEST address
(qemu 10.0 and upper) or via the legacy way via an offset obtained
from the hardware_errors firmware file.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
---
hw/acpi/generic_event_device.c | 2 ++
hw/arm/virt-acpi-build.c | 18 ++++++++++++++++--
hw/core/machine.c | 5 ++++-
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
index d292f61b4e41..3cf9dab0d01a 100644
--- a/hw/acpi/generic_event_device.c
+++ b/hw/acpi/generic_event_device.c
@@ -318,6 +318,8 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
static const Property acpi_ged_properties[] = {
DEFINE_PROP_UINT32("ged-event", AcpiGedState, ged_event_bitmap, 0),
+ DEFINE_PROP_BOOL("x-has-hest-addr", AcpiGedState,
+ ghes_state.use_hest_addr, false),
};
static const VMStateDescription vmstate_memhp_state = {
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index da3ebf403ef9..3126234e657d 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -893,6 +893,10 @@ static const AcpiNotificationSourceId hest_ghes_notify[] = {
{ ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
};
+static const AcpiNotificationSourceId hest_ghes_notify_10_0[] = {
+ { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
+};
+
static
void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
{
@@ -947,15 +951,25 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
if (vms->ras) {
AcpiGedState *acpi_ged_state;
+ static const AcpiNotificationSourceId *notify;
+ unsigned int notify_sz;
AcpiGhesState *ags;
acpi_ged_state = ACPI_GED(vms->acpi_dev);
ags = &acpi_ged_state->ghes_state;
if (ags) {
acpi_add_table(table_offsets, tables_blob);
+
+ if (!ags->use_hest_addr) {
+ notify = hest_ghes_notify_10_0;
+ notify_sz = ARRAY_SIZE(hest_ghes_notify_10_0);
+ } else {
+ notify = hest_ghes_notify;
+ notify_sz = ARRAY_SIZE(hest_ghes_notify);
+ }
+
acpi_build_hest(ags, tables_blob, tables->hardware_errors,
- tables->linker, hest_ghes_notify,
- ARRAY_SIZE(hest_ghes_notify),
+ tables->linker, notify, notify_sz,
vms->oem_id, vms->oem_table_id);
}
}
diff --git a/hw/core/machine.c b/hw/core/machine.c
index b8ae155dfa11..dfd36cf063c7 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -35,9 +35,12 @@
#include "hw/virtio/virtio-pci.h"
#include "hw/virtio/virtio-net.h"
#include "hw/virtio/virtio-iommu.h"
+#include "hw/acpi/generic_event_device.h"
#include "audio/audio.h"
-GlobalProperty hw_compat_10_0[] = {};
+GlobalProperty hw_compat_10_0[] = {
+ { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
+};
const size_t hw_compat_10_0_len = G_N_ELEMENTS(hw_compat_10_0);
GlobalProperty hw_compat_9_2[] = {
--
2.49.0On Tue, 20 May 2025 08:41:31 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Create a new property (x-has-hest-addr) and use it to detect if
> the GHES table offsets can be calculated from the HEST address
> (qemu 10.0 and upper) or via the legacy way via an offset obtained
> from the hardware_errors firmware file.
it doesn't apply to current master anymore
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
> ---
> hw/acpi/generic_event_device.c | 2 ++
> hw/arm/virt-acpi-build.c | 18 ++++++++++++++++--
> hw/core/machine.c | 5 ++++-
> 3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> index d292f61b4e41..3cf9dab0d01a 100644
> --- a/hw/acpi/generic_event_device.c
> +++ b/hw/acpi/generic_event_device.c
> @@ -318,6 +318,8 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
>
> static const Property acpi_ged_properties[] = {
> DEFINE_PROP_UINT32("ged-event", AcpiGedState, ged_event_bitmap, 0),
> + DEFINE_PROP_BOOL("x-has-hest-addr", AcpiGedState,
> + ghes_state.use_hest_addr, false),
> };
>
> static const VMStateDescription vmstate_memhp_state = {
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index da3ebf403ef9..3126234e657d 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -893,6 +893,10 @@ static const AcpiNotificationSourceId hest_ghes_notify[] = {
> { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> };
>
> +static const AcpiNotificationSourceId hest_ghes_notify_10_0[] = {
> + { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> +};
> +
> static
> void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> {
> @@ -947,15 +951,25 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
>
> if (vms->ras) {
> AcpiGedState *acpi_ged_state;
> + static const AcpiNotificationSourceId *notify;
> + unsigned int notify_sz;
> AcpiGhesState *ags;
>
> acpi_ged_state = ACPI_GED(vms->acpi_dev);
> ags = &acpi_ged_state->ghes_state;
> if (ags) {
> acpi_add_table(table_offsets, tables_blob);
> +
> + if (!ags->use_hest_addr) {
> + notify = hest_ghes_notify_10_0;
> + notify_sz = ARRAY_SIZE(hest_ghes_notify_10_0);
> + } else {
> + notify = hest_ghes_notify;
> + notify_sz = ARRAY_SIZE(hest_ghes_notify);
> + }
> +
> acpi_build_hest(ags, tables_blob, tables->hardware_errors,
> - tables->linker, hest_ghes_notify,
> - ARRAY_SIZE(hest_ghes_notify),
> + tables->linker, notify, notify_sz,
> vms->oem_id, vms->oem_table_id);
> }
> }
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index b8ae155dfa11..dfd36cf063c7 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -35,9 +35,12 @@
> #include "hw/virtio/virtio-pci.h"
> #include "hw/virtio/virtio-net.h"
> #include "hw/virtio/virtio-iommu.h"
> +#include "hw/acpi/generic_event_device.h"
> #include "audio/audio.h"
>
> -GlobalProperty hw_compat_10_0[] = {};
> +GlobalProperty hw_compat_10_0[] = {
> + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> +};
> const size_t hw_compat_10_0_len = G_N_ELEMENTS(hw_compat_10_0);
>
> GlobalProperty hw_compat_9_2[] = {
On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> On Tue, 20 May 2025 08:41:31 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > Create a new property (x-has-hest-addr) and use it to detect if
> > the GHES table offsets can be calculated from the HEST address
> > (qemu 10.0 and upper) or via the legacy way via an offset obtained
> > from the hardware_errors firmware file.
>
>
> it doesn't apply to current master anymore
indeed. Mauro?
>
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > Reviewed-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> > hw/acpi/generic_event_device.c | 2 ++
> > hw/arm/virt-acpi-build.c | 18 ++++++++++++++++--
> > hw/core/machine.c | 5 ++++-
> > 3 files changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> > index d292f61b4e41..3cf9dab0d01a 100644
> > --- a/hw/acpi/generic_event_device.c
> > +++ b/hw/acpi/generic_event_device.c
> > @@ -318,6 +318,8 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
> >
> > static const Property acpi_ged_properties[] = {
> > DEFINE_PROP_UINT32("ged-event", AcpiGedState, ged_event_bitmap, 0),
> > + DEFINE_PROP_BOOL("x-has-hest-addr", AcpiGedState,
> > + ghes_state.use_hest_addr, false),
> > };
> >
> > static const VMStateDescription vmstate_memhp_state = {
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index da3ebf403ef9..3126234e657d 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -893,6 +893,10 @@ static const AcpiNotificationSourceId hest_ghes_notify[] = {
> > { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> > };
> >
> > +static const AcpiNotificationSourceId hest_ghes_notify_10_0[] = {
> > + { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> > +};
> > +
> > static
> > void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> > {
> > @@ -947,15 +951,25 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> >
> > if (vms->ras) {
> > AcpiGedState *acpi_ged_state;
> > + static const AcpiNotificationSourceId *notify;
> > + unsigned int notify_sz;
> > AcpiGhesState *ags;
> >
> > acpi_ged_state = ACPI_GED(vms->acpi_dev);
> > ags = &acpi_ged_state->ghes_state;
> > if (ags) {
> > acpi_add_table(table_offsets, tables_blob);
> > +
> > + if (!ags->use_hest_addr) {
> > + notify = hest_ghes_notify_10_0;
> > + notify_sz = ARRAY_SIZE(hest_ghes_notify_10_0);
> > + } else {
> > + notify = hest_ghes_notify;
> > + notify_sz = ARRAY_SIZE(hest_ghes_notify);
> > + }
> > +
> > acpi_build_hest(ags, tables_blob, tables->hardware_errors,
> > - tables->linker, hest_ghes_notify,
> > - ARRAY_SIZE(hest_ghes_notify),
> > + tables->linker, notify, notify_sz,
> > vms->oem_id, vms->oem_table_id);
> > }
> > }
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index b8ae155dfa11..dfd36cf063c7 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -35,9 +35,12 @@
> > #include "hw/virtio/virtio-pci.h"
> > #include "hw/virtio/virtio-net.h"
> > #include "hw/virtio/virtio-iommu.h"
> > +#include "hw/acpi/generic_event_device.h"
> > #include "audio/audio.h"
> >
> > -GlobalProperty hw_compat_10_0[] = {};
> > +GlobalProperty hw_compat_10_0[] = {
> > + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> > +};
> > const size_t hw_compat_10_0_len = G_N_ELEMENTS(hw_compat_10_0);
> >
> > GlobalProperty hw_compat_9_2[] = {
On Fri, 30 May 2025 08:01:28 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> > On Tue, 20 May 2025 08:41:31 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >
> > > Create a new property (x-has-hest-addr) and use it to detect if
> > > the GHES table offsets can be calculated from the HEST address
> > > (qemu 10.0 and upper) or via the legacy way via an offset obtained
> > > from the hardware_errors firmware file.
> >
> >
> > it doesn't apply to current master anymore
>
> indeed. Mauro?
Michael,
it's trivial conflict in machine compat,
could you fix it up while applying?
we have another series in queue that depends on this one being in merged.
>
> >
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > Reviewed-by: Igor Mammedov <imammedo@redhat.com>
> > > ---
> > > hw/acpi/generic_event_device.c | 2 ++
> > > hw/arm/virt-acpi-build.c | 18 ++++++++++++++++--
> > > hw/core/machine.c | 5 ++++-
> > > 3 files changed, 22 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> > > index d292f61b4e41..3cf9dab0d01a 100644
> > > --- a/hw/acpi/generic_event_device.c
> > > +++ b/hw/acpi/generic_event_device.c
> > > @@ -318,6 +318,8 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
> > >
> > > static const Property acpi_ged_properties[] = {
> > > DEFINE_PROP_UINT32("ged-event", AcpiGedState, ged_event_bitmap, 0),
> > > + DEFINE_PROP_BOOL("x-has-hest-addr", AcpiGedState,
> > > + ghes_state.use_hest_addr, false),
> > > };
> > >
> > > static const VMStateDescription vmstate_memhp_state = {
> > > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > > index da3ebf403ef9..3126234e657d 100644
> > > --- a/hw/arm/virt-acpi-build.c
> > > +++ b/hw/arm/virt-acpi-build.c
> > > @@ -893,6 +893,10 @@ static const AcpiNotificationSourceId hest_ghes_notify[] = {
> > > { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> > > };
> > >
> > > +static const AcpiNotificationSourceId hest_ghes_notify_10_0[] = {
> > > + { ACPI_HEST_SRC_ID_SYNC, ACPI_GHES_NOTIFY_SEA },
> > > +};
> > > +
> > > static
> > > void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> > > {
> > > @@ -947,15 +951,25 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables)
> > >
> > > if (vms->ras) {
> > > AcpiGedState *acpi_ged_state;
> > > + static const AcpiNotificationSourceId *notify;
> > > + unsigned int notify_sz;
> > > AcpiGhesState *ags;
> > >
> > > acpi_ged_state = ACPI_GED(vms->acpi_dev);
> > > ags = &acpi_ged_state->ghes_state;
> > > if (ags) {
> > > acpi_add_table(table_offsets, tables_blob);
> > > +
> > > + if (!ags->use_hest_addr) {
> > > + notify = hest_ghes_notify_10_0;
> > > + notify_sz = ARRAY_SIZE(hest_ghes_notify_10_0);
> > > + } else {
> > > + notify = hest_ghes_notify;
> > > + notify_sz = ARRAY_SIZE(hest_ghes_notify);
> > > + }
> > > +
> > > acpi_build_hest(ags, tables_blob, tables->hardware_errors,
> > > - tables->linker, hest_ghes_notify,
> > > - ARRAY_SIZE(hest_ghes_notify),
> > > + tables->linker, notify, notify_sz,
> > > vms->oem_id, vms->oem_table_id);
> > > }
> > > }
> > > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > > index b8ae155dfa11..dfd36cf063c7 100644
> > > --- a/hw/core/machine.c
> > > +++ b/hw/core/machine.c
> > > @@ -35,9 +35,12 @@
> > > #include "hw/virtio/virtio-pci.h"
> > > #include "hw/virtio/virtio-net.h"
> > > #include "hw/virtio/virtio-iommu.h"
> > > +#include "hw/acpi/generic_event_device.h"
> > > #include "audio/audio.h"
> > >
> > > -GlobalProperty hw_compat_10_0[] = {};
> > > +GlobalProperty hw_compat_10_0[] = {
> > > + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> > > +};
> > > const size_t hw_compat_10_0_len = G_N_ELEMENTS(hw_compat_10_0);
> > >
> > > GlobalProperty hw_compat_9_2[] = {
>
Em Fri, 30 May 2025 16:49:03 +0200
Igor Mammedov <imammedo@redhat.com> escreveu:
> On Fri, 30 May 2025 08:01:28 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> > > On Tue, 20 May 2025 08:41:31 +0200
> > > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > >
> > > > Create a new property (x-has-hest-addr) and use it to detect if
> > > > the GHES table offsets can be calculated from the HEST address
> > > > (qemu 10.0 and upper) or via the legacy way via an offset obtained
> > > > from the hardware_errors firmware file.
> > >
> > >
> > > it doesn't apply to current master anymore
> >
> > indeed. Mauro?
>
> Michael,
> it's trivial conflict in machine compat,
> could you fix it up while applying?
IMHO, that's the best. The thing is, as code gets merged upstream with
backports, conflicts happen.
I can re-send the series, if you prefer, as I'm keeping it rebasing it
from time to time at:
https://gitlab.com/mchehab_kernel/qemu/-/tree/qemu_submitted?ref_type=heads
(it is on the top of upstream/master)
But even that might have conflicts on your test tree if you pick
other patches touching this backport table:
> -GlobalProperty hw_compat_10_0[] = {};
> +GlobalProperty hw_compat_10_0[] = {
> + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> +};
(this was the code when I sent the PR. When applying upstream,
such hunk is now(*):
GlobalProperty hw_compat_10_0[] = {
{ "scsi-hd", "dpofua", "off" },
+ { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
};
(*) https://gitlab.com/mchehab_kernel/qemu/-/commit/08c4859f8c6f36d7dccf2b773be88847e5d1fe0c
If you still prefer that I resubmit the entire PR, let me know.
Regards,
Mauro
On Fri, 30 May 2025 22:18:10 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Em Fri, 30 May 2025 16:49:03 +0200
> Igor Mammedov <imammedo@redhat.com> escreveu:
>
> > On Fri, 30 May 2025 08:01:28 -0400
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> > > On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> > > > On Tue, 20 May 2025 08:41:31 +0200
> > > > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > > >
> > > > > Create a new property (x-has-hest-addr) and use it to detect if
> > > > > the GHES table offsets can be calculated from the HEST address
> > > > > (qemu 10.0 and upper) or via the legacy way via an offset obtained
> > > > > from the hardware_errors firmware file.
> > > >
> > > >
> > > > it doesn't apply to current master anymore
> > >
> > > indeed. Mauro?
> >
> > Michael,
> > it's trivial conflict in machine compat,
> > could you fix it up while applying?
>
> IMHO, that's the best. The thing is, as code gets merged upstream with
> backports, conflicts happen.
>
> I can re-send the series, if you prefer, as I'm keeping it rebasing it
> from time to time at:
> https://gitlab.com/mchehab_kernel/qemu/-/tree/qemu_submitted?ref_type=heads
>
> (it is on the top of upstream/master)
>
> But even that might have conflicts on your test tree if you pick
> other patches touching this backport table:
>
> > -GlobalProperty hw_compat_10_0[] = {};
> > +GlobalProperty hw_compat_10_0[] = {
> > + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> > +};
>
> (this was the code when I sent the PR. When applying upstream,
> such hunk is now(*):
>
> GlobalProperty hw_compat_10_0[] = {
> { "scsi-hd", "dpofua", "off" },
> + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> };
>
>
> (*) https://gitlab.com/mchehab_kernel/qemu/-/commit/08c4859f8c6f36d7dccf2b773be88847e5d1fe0c
>
> If you still prefer that I resubmit the entire PR, let me know.
If it's the only patch that needs rebase and doesn't affect the rest,
I'd say there is no need to spam the list with whole series respin,
just post rebased v10 12/20 as reply here
If it's more than that, respin series.
>
> Regards,
> Mauro
>
Em Mon, 2 Jun 2025 12:22:44 +0200
Igor Mammedov <imammedo@redhat.com> escreveu:
> On Fri, 30 May 2025 22:18:10 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > Em Fri, 30 May 2025 16:49:03 +0200
> > Igor Mammedov <imammedo@redhat.com> escreveu:
> >
> > > On Fri, 30 May 2025 08:01:28 -0400
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >
> > > > On Wed, May 28, 2025 at 05:42:12PM +0200, Igor Mammedov wrote:
> > > > > On Tue, 20 May 2025 08:41:31 +0200
> > > > > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > > > >
> > > > > > Create a new property (x-has-hest-addr) and use it to detect if
> > > > > > the GHES table offsets can be calculated from the HEST address
> > > > > > (qemu 10.0 and upper) or via the legacy way via an offset obtained
> > > > > > from the hardware_errors firmware file.
> > > > >
> > > > >
> > > > > it doesn't apply to current master anymore
> > > >
> > > > indeed. Mauro?
> > >
> > > Michael,
> > > it's trivial conflict in machine compat,
> > > could you fix it up while applying?
> >
> > IMHO, that's the best. The thing is, as code gets merged upstream with
> > backports, conflicts happen.
> >
> > I can re-send the series, if you prefer, as I'm keeping it rebasing it
> > from time to time at:
> > https://gitlab.com/mchehab_kernel/qemu/-/tree/qemu_submitted?ref_type=heads
> >
> > (it is on the top of upstream/master)
> >
> > But even that might have conflicts on your test tree if you pick
> > other patches touching this backport table:
> >
> > > -GlobalProperty hw_compat_10_0[] = {};
> > > +GlobalProperty hw_compat_10_0[] = {
> > > + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> > > +};
> >
> > (this was the code when I sent the PR. When applying upstream,
> > such hunk is now(*):
> >
> > GlobalProperty hw_compat_10_0[] = {
> > { "scsi-hd", "dpofua", "off" },
> > + { TYPE_ACPI_GED, "x-has-hest-addr", "false" },
> > };
> >
> >
> > (*) https://gitlab.com/mchehab_kernel/qemu/-/commit/08c4859f8c6f36d7dccf2b773be88847e5d1fe0c
> >
> > If you still prefer that I resubmit the entire PR, let me know.
>
> If it's the only patch that needs rebase and doesn't affect the rest,
> I'd say there is no need to spam the list with whole series respin,
> just post rebased v10 12/20 as reply here
>
> If it's more than that, respin series.
This is the only patch with conflicts. I'll send a v10 of it.
>
> >
> > Regards,
> > Mauro
> >
>
Thanks,
Mauro
© 2016 - 2025 Red Hat, Inc.