diff mbox

[v2] acpi: Use apic_id_limit when calculating legacy ACPI table size

Message ID 1478882742-14686-1-git-send-email-ehabkost@redhat.com
State New
Headers show

Commit Message

Eduardo Habkost Nov. 11, 2016, 4:45 p.m. UTC
The code that calculates the legacy ACPI table size for migration
compatibility uses max_cpus when calculating legacy_aml_len (the size of
the DSDT and SSDT tables). However, the SSDT grows according to APIC ID
limit, not max_cpus.

The bug is not triggered very often because of the 4k alignment on the
table size. But it can be triggered if you are unlucky enough to cross a
4k boundary.

Change the legacy_aml_len calculation to use apic_id_limit, to calculate
the right size.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
This patch was submitted in 2014 and reviewed by Paolo. Only
today I noticed that it was never merged.

Changes v1 -> v2:
* Use pcms->apic_id_limit, as guest_info doesn't exist anymore
---
 hw/i386/acpi-build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Michael S. Tsirkin Nov. 11, 2016, 5:13 p.m. UTC | #1
On Fri, Nov 11, 2016 at 02:45:42PM -0200, Eduardo Habkost wrote:
> The code that calculates the legacy ACPI table size for migration
> compatibility uses max_cpus when calculating legacy_aml_len (the size of
> the DSDT and SSDT tables). However, the SSDT grows according to APIC ID
> limit, not max_cpus.
> 
> The bug is not triggered very often because of the 4k alignment on the
> table size. But it can be triggered if you are unlucky enough to cross a
> 4k boundary.
> 
> Change the legacy_aml_len calculation to use apic_id_limit, to calculate
> the right size.
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

Does this affect migration in some way?

> ---
> This patch was submitted in 2014 and reviewed by Paolo. Only
> today I noticed that it was never merged.
> 
> Changes v1 -> v2:
> * Use pcms->apic_id_limit, as guest_info doesn't exist anymore
> ---
>  hw/i386/acpi-build.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index c02f408..bb66446 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2859,7 +2859,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>           */
>          int legacy_aml_len =
>              pcmc->legacy_acpi_table_size +
> -            ACPI_BUILD_LEGACY_CPU_AML_SIZE * max_cpus;
> +            ACPI_BUILD_LEGACY_CPU_AML_SIZE * pcms->apic_id_limit;
>          int legacy_table_size =
>              ROUND_UP(tables_blob->len - aml_len + legacy_aml_len,
>                       ACPI_BUILD_ALIGN_SIZE);
> -- 
> 2.7.4
Eduardo Habkost Nov. 11, 2016, 5:21 p.m. UTC | #2
On Fri, Nov 11, 2016 at 07:13:25PM +0200, Michael S. Tsirkin wrote:
> On Fri, Nov 11, 2016 at 02:45:42PM -0200, Eduardo Habkost wrote:
> > The code that calculates the legacy ACPI table size for migration
> > compatibility uses max_cpus when calculating legacy_aml_len (the size of
> > the DSDT and SSDT tables). However, the SSDT grows according to APIC ID
> > limit, not max_cpus.
> > 
> > The bug is not triggered very often because of the 4k alignment on the
> > table size. But it can be triggered if you are unlucky enough to cross a
> > 4k boundary.
> > 
> > Change the legacy_aml_len calculation to use apic_id_limit, to calculate
> > the right size.
> > 
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> Does this affect migration in some way?

It affects migration in the same way that a wrong
PCMachineClass::legacy_acpi_table_size value would. (I don't know
what are the exact symptoms when the sizes are wrong)

In 2014 I could even trigger the "Warning: migration may not
work." message before applying this fix, I think it was because
the difference between aml_len and legacy_aml_len was smaller.
But something changed in between and the effects of the wrong
size calculation are harder to see.

> 
> > ---
> > This patch was submitted in 2014 and reviewed by Paolo. Only
> > today I noticed that it was never merged.
> > 
> > Changes v1 -> v2:
> > * Use pcms->apic_id_limit, as guest_info doesn't exist anymore
> > ---
> >  hw/i386/acpi-build.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index c02f408..bb66446 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -2859,7 +2859,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
> >           */
> >          int legacy_aml_len =
> >              pcmc->legacy_acpi_table_size +
> > -            ACPI_BUILD_LEGACY_CPU_AML_SIZE * max_cpus;
> > +            ACPI_BUILD_LEGACY_CPU_AML_SIZE * pcms->apic_id_limit;
> >          int legacy_table_size =
> >              ROUND_UP(tables_blob->len - aml_len + legacy_aml_len,
> >                       ACPI_BUILD_ALIGN_SIZE);
> > -- 
> > 2.7.4
diff mbox

Patch

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index c02f408..bb66446 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2859,7 +2859,7 @@  void acpi_build(AcpiBuildTables *tables, MachineState *machine)
          */
         int legacy_aml_len =
             pcmc->legacy_acpi_table_size +
-            ACPI_BUILD_LEGACY_CPU_AML_SIZE * max_cpus;
+            ACPI_BUILD_LEGACY_CPU_AML_SIZE * pcms->apic_id_limit;
         int legacy_table_size =
             ROUND_UP(tables_blob->len - aml_len + legacy_aml_len,
                      ACPI_BUILD_ALIGN_SIZE);