[v3,0/4] acpi: Set proper maximum size for "etc/table-loader" blob

Message

David Hildenbrand March 4, 2021, 10:55 a.m. UTC

Fix and cleanup initializing the maximum size of mutable ACPI blobs.

v1/v2 -> v3:
- 'acpi: Set proper maximum size for "etc/table-loader" blob'
-- Move "etc/table-loader" change to separate patch
-- Extend description
-- Fixup maximum size (now really use 64k)
- Add some patches to cleanup/refactor the code. I avoided using a new
  enum for the different tables for now, using the table names should be
  good enough and is simple.

David Hildenbrand (4):
  acpi: Set proper maximum size for "etc/table-loader" blob
  microvm: Don't open-code "etc/table-loader"
  acpi: Move maximum size logic into acpi_add_rom_blob()
  acpi: Set proper maximum size for "etc/acpi/rsdp" blob

 hw/acpi/utils.c             | 17 +++++++++++++++--
 hw/arm/virt-acpi-build.c    | 12 ++++++------
 hw/i386/acpi-build.c        |  7 +++----
 hw/i386/acpi-microvm.c      | 16 ++++++----------
 include/hw/acpi/aml-build.h |  3 ---
 include/hw/acpi/utils.h     |  3 +--
 6 files changed, 31 insertions(+), 27 deletions(-)

Comments

Laszlo Ersek March 4, 2021, 8:22 p.m. UTC | #1

On 03/04/21 11:55, David Hildenbrand wrote:
> Fix and cleanup initializing the maximum size of mutable ACPI blobs.
> 
> v1/v2 -> v3:
> - 'acpi: Set proper maximum size for "etc/table-loader" blob'
> -- Move "etc/table-loader" change to separate patch
> -- Extend description
> -- Fixup maximum size (now really use 64k)
> - Add some patches to cleanup/refactor the code. I avoided using a new
>   enum for the different tables for now, using the table names should be
>   good enough and is simple.
> 
> David Hildenbrand (4):
>   acpi: Set proper maximum size for "etc/table-loader" blob
>   microvm: Don't open-code "etc/table-loader"
>   acpi: Move maximum size logic into acpi_add_rom_blob()
>   acpi: Set proper maximum size for "etc/acpi/rsdp" blob
> 
>  hw/acpi/utils.c             | 17 +++++++++++++++--
>  hw/arm/virt-acpi-build.c    | 12 ++++++------
>  hw/i386/acpi-build.c        |  7 +++----
>  hw/i386/acpi-microvm.c      | 16 ++++++----------
>  include/hw/acpi/aml-build.h |  3 ---
>  include/hw/acpi/utils.h     |  3 +--
>  6 files changed, 31 insertions(+), 27 deletions(-)
> 

series
Reviewed-by: Laszlo Ersek <[e-mail]>

David Hildenbrand March 15, 2021, 8:57 a.m. UTC | #2

On 04.03.21 11:55, David Hildenbrand wrote:
> Fix and cleanup initializing the maximum size of mutable ACPI blobs.
> 
> v1/v2 -> v3:
> - 'acpi: Set proper maximum size for "etc/table-loader" blob'
> -- Move "etc/table-loader" change to separate patch
> -- Extend description
> -- Fixup maximum size (now really use 64k)
> - Add some patches to cleanup/refactor the code. I avoided using a new
>    enum for the different tables for now, using the table names should be
>    good enough and is simple.
> 

Ping, would be nice to get this into v6.0

Igor Mammedov March 15, 2021, 2:06 p.m. UTC | #3

On Thu,  4 Mar 2021 11:55:50 +0100
David Hildenbrand <[e-mail]> wrote:

> Fix and cleanup initializing the maximum size of mutable ACPI blobs.
> 
> v1/v2 -> v3:
> - 'acpi: Set proper maximum size for "etc/table-loader" blob'
> -- Move "etc/table-loader" change to separate patch
> -- Extend description
> -- Fixup maximum size (now really use 64k)
> - Add some patches to cleanup/refactor the code. I avoided using a new
>   enum for the different tables for now, using the table names should be
>   good enough and is simple.
> 
> David Hildenbrand (4):
>   acpi: Set proper maximum size for "etc/table-loader" blob
>   microvm: Don't open-code "etc/table-loader"
>   acpi: Move maximum size logic into acpi_add_rom_blob()
>   acpi: Set proper maximum size for "etc/acpi/rsdp" blob
> 
>  hw/acpi/utils.c             | 17 +++++++++++++++--
>  hw/arm/virt-acpi-build.c    | 12 ++++++------
>  hw/i386/acpi-build.c        |  7 +++----
>  hw/i386/acpi-microvm.c      | 16 ++++++----------
>  include/hw/acpi/aml-build.h |  3 ---
>  include/hw/acpi/utils.h     |  3 +--
>  6 files changed, 31 insertions(+), 27 deletions(-)
> 

Reviewed-by: Igor Mammedov <[e-mail]>