Support for ACPI 1.0

Support for ACPI 1.0

[Evan Lloyd]

There is some wonderfully convoluted code in MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
A major cause of the complexity arises from the special cases related to support for "EFI_ACPI_TABLE_VERSION_1_0B" or not ("ACPI_TABLE_VERSION_GTE_2_0").

We are seeing problems (SCT fails) related to this with the current code, and have been looking at a fix.

However, it seems reasonable to question the requirement to support ACPI 1.0 nowadays.
Is there any need to retain support for such obsolete table versions?
Should there be, could it at least be split out into a distinct build option?

Regards,
Evan

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Support for ACPI 1.0

[Laszlo Ersek]

On 11/15/16 14:08, Evan Lloyd wrote:
> There is some wonderfully convoluted code in MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> A major cause of the complexity arises from the special cases related to support for "EFI_ACPI_TABLE_VERSION_1_0B" or not ("ACPI_TABLE_VERSION_GTE_2_0").
> 
> We are seeing problems (SCT fails) related to this with the current code, and have been looking at a fix.
> 
> However, it seems reasonable to question the requirement to support ACPI 1.0 nowadays.
> Is there any need to retain support for such obsolete table versions?
> Should there be, could it at least be split out into a distinct build option?

It seems that this can be controlled through PcdAcpiExposedTableVersions -- is that insufficient for your purpose? From "MdeModulePkg/MdeModulePkg.dec":

  ## Indicates which ACPI versions are targeted by the ACPI tables exposed to the OS
  #  These values are aligned with the definitions in MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
  #   BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.<BR>
  #   BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.<BR>
  #   BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.<BR>
  #   BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.<BR>
  #   BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.<BR>
  # @Prompt Exposed ACPI table versions.
  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|UINT32|0x0001004c

See commit e0692789058ee for example.

Thanks!
Laszlo

> 
> Regards,
> Evan
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

Re: Support for ACPI 1.0

[Evan Lloyd]

Hi Laszlo.
Thank you for the response.  Comments inline below.

>-----Original Message-----
>From: Laszlo Ersek [mailto:lersek@redhat.com]
>Sent: 15 November 2016 16:56
>To: Evan Lloyd; edk2-devel (edk2-devel@lists.01.org);
>ard.biesheuvel@linaro.org; Star Zeng; Jordan Justen; Feng Tian
>Cc: Lorenzo Pieralisi; Leif Lindholm
>Subject: Re: [edk2] Support for ACPI 1.0
>
>On 11/15/16 14:08, Evan Lloyd wrote:
>> There is some wonderfully convoluted code in
>MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
>> A major cause of the complexity arises from the special cases related to
>support for "EFI_ACPI_TABLE_VERSION_1_0B" or not
>("ACPI_TABLE_VERSION_GTE_2_0").
>>
>> We are seeing problems (SCT fails) related to this with the current code,
>and have been looking at a fix.
>>
>> However, it seems reasonable to question the requirement to support
>ACPI 1.0 nowadays.
>> Is there any need to retain support for such obsolete table versions?
>> Should there be, could it at least be split out into a distinct build option?
>
>It seems that this can be controlled through PcdAcpiExposedTableVersions -
>- is that insufficient for your purpose? From

The USE of the code can indeed be controlled with the Pcd.
However my point is that to accommodate the idiosyncrasies of "ACPI_1_0B", the code is complex and obscure.
It also has bugs, largely because of that complexity.

Were ACPI 1.0 support removed, it would become far simpler, more maintainable, and easier to debug.
All the optional code for VERSION_1_0B or GTE_2_0 would become redundant, and the updates we need to make would be simplified.

For ARM, we only really care about ACPI 5.0 or later.
I do not know what the support requirements might be for other platforms, but ACPI 2.0 came out in 2000, so it seems reasonable to encourage people into this century, if not this decade.

>"MdeModulePkg/MdeModulePkg.dec":
>
>  ## Indicates which ACPI versions are targeted by the ACPI tables exposed
>to the OS
>  #  These values are aligned with the definitions in
>MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>  #   BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.<BR>
>  #   BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.<BR>
>  #   BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.<BR>
>  #   BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.<BR>
>  #   BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.<BR>
>  # @Prompt Exposed ACPI table versions.
>

Wot, no ACPI 6?  (That is one issue we have found, especially with the GTE_2_0 macro.)

>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|
>UINT32|0x0001004c
>
>See commit e0692789058ee for example.
>
>Thanks!
>Laszlo
>
>>
>> Regards,
>> Evan
...
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.