From: "Sami Mujawar" <sami.mujawar@arm.com>
To: Name <username@nvidia.com>,
devel@edk2.groups.io, Alexei.Fedorov@arm.com,
pierre.gondois@arm.com, michael.d.kinney@intel.com,
gaoliming@byosoft.com.cn, zhiguang.liu@intel.com
Cc: Swatisri Kantamsetti <swatisrik@nvidia.com>, "nd@arm.com" <nd@arm.com>
Subject: Re: [PATCH 1/2] DynamicTablesPkg: IORT generator updates for Rev E.e spec
Date: Mon, 6 Feb 2023 10:38:14 +0000 [thread overview]
Message-ID: <cf07f8c9-4c02-4502-0aa6-30d6cb220120@arm.com> (raw)
In-Reply-To: <13bc39429583f0129b2935970df6489191004ad2.1674671138.git.swatisrik@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 5189 bytes --]
Hi Swatisri,
Thank you for this patch,
I have some suggestions marked inline as [SAMI].
Regards,
Sami Mujawar
On 25/01/2023 06:40 pm, Name wrote:
> From: Swatisri Kantamsetti<swatisrik@nvidia.com>
>
> The IO Remapping Table, Platform Design Document, Revision E.e,
> Sept 2022 (https://developer.arm.com/documentation/den0049/ee)
> added flags in SMMUv3 node for validity of ID mappings for MSIs
> related to control interrupts.
> It makes one small addition to SMMUv3 nodes to
> describe MSI support independently of wired GSIV support
>
> Therefore, update the IORT generator to:
> - increment IORT table revision to 6
> - increment SMMUV3 node revision to 5
> - for SMMUV3 node revision >=5 check the DeviceID mapping index
> valid flag to populate DeviceIdMappingIndex field
> - preserve backward compatibility.
>
> Signed-off-by: Swatisri Kantamsetti<swatisrik@nvidia.com>
> ---
> .../Acpi/Arm/AcpiIortLibArm/IortGenerator.c | 36 ++++++++++++++-----
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c b/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
> index f28973c1a8..235a475629 100644
> --- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
> +++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
[SAMI] Can you update the file header with the IORT Spec revision, please?
> @@ -1554,9 +1554,14 @@ AddSmmuV3Nodes (
> {
> SmmuV3Node->Node.Revision = 2;
> SmmuV3Node->Node.Identifier = EFI_ACPI_RESERVED_DWORD;
> - } else {
> + } else if (AcpiTableInfo->AcpiTableRevision <
> + EFI_ACPI_IO_REMAPPING_TABLE_REVISION_06)
> + {
> SmmuV3Node->Node.Revision = 4;
> SmmuV3Node->Node.Identifier = NodeList->Identifier;
> + } else {
> + SmmuV3Node->Node.Revision = 5;
> + SmmuV3Node->Node.Identifier = NodeList->Identifier;
> }
>
> // SMMUv3 specific data
> @@ -1577,12 +1582,27 @@ AddSmmuV3Nodes (
> SmmuV3Node->ProximityDomain = 0;
> }
> <SNIP>
> - if ((SmmuV3Node->Event != 0) && (SmmuV3Node->Pri != 0) &&
> - (SmmuV3Node->Gerr != 0) && (SmmuV3Node->Sync != 0))
> - {
> - // If all the SMMU control interrupts are GSIV based,
> - // the DeviceID mapping index field is ignored.
> - SmmuV3Node->DeviceIdMappingIndex = 0;
> + /* DeviceID mapping valid flag was introduced in IORT rev E.e
> + * for SMMUV3 nodes rev. > 5.
> + * For older revisions, if all the SMMU control interrupts are GSIV
> + * based, DeviceID mapping index field is ignored.
> + * If the DeviceID mapping index valid flag is set to 0,
> + * DeviceID mapping index field must be ignored.
> + * Where the SMMU uses message signaled interrupts for
> + * its control interrupts, DeviceId Mapping Index contains an
> + * index into the array of ID mapping.
> + */
> +
> + if ((SmmuV3Node->Node.Revision < 5) || (!(SmmuV3Node->Flags & EFI_ACPI_IORT_SMMUv3_FLAG_DEVICEID_VALID))) {
> + if ((SmmuV3Node->Event != 0) && (SmmuV3Node->Pri != 0) &&
> + (SmmuV3Node->Gerr != 0) && (SmmuV3Node->Sync != 0))
> + {
> + // If all the SMMU control interrupts are GSIV based,
> + // the DeviceID mapping index field is ignored.
> + SmmuV3Node->DeviceIdMappingIndex = 0;
> + } else {
> + SmmuV3Node->DeviceIdMappingIndex = NodeList->DeviceIdMappingIndex;
> + }
> } else {
> SmmuV3Node->DeviceIdMappingIndex = NodeList->DeviceIdMappingIndex;
> }
</SNIP>
[SAMI] I think the above code should be changed to the following:
/* For older SMMUV3 nodes rev. < 5.
If all the SMMU control interrupts are GSIV based,
the DeviceID mapping index field is ignored.
DeviceID mapping valid flag was introduced in IORT rev E.e
for SMMUV3 nodes rev. > 5.
If the DeviceID mapping index valid flag is set to 0,
DeviceID mapping index field must be ignored.
Where the SMMU uses message signaled interrupts for
its control interrupts, DeviceId Mapping Index contains an
index into the array of ID mapping.
*/
if (((SmmuV3Node->Node.Revision < 5) &&
(SmmuV3Node->Event != 0) &&
(SmmuV3Node->Pri != 0) &&
(SmmuV3Node->Gerr != 0) &&
(SmmuV3Node->Sync != 0)
) ||
((SmmuV3Node->Node.Revision >= 5) &&
((SmmuV3Node->Flags & EFI_ACPI_IORT_SMMUv3_FLAG_DEVICEID_VALID) == 0))
) {
SmmuV3Node->DeviceIdMappingIndex = 0;
} else {
SmmuV3Node->DeviceIdMappingIndex = NodeList->DeviceIdMappingIndex;
}
Can you check, please?
[/SAMI]
> @@ -2819,7 +2839,7 @@ ACPI_IORT_GENERATOR IortGenerator = {
> // ACPI Table Signature
> EFI_ACPI_6_4_IO_REMAPPING_TABLE_SIGNATURE,
> // ACPI Table Revision supported by this Generator
> - EFI_ACPI_IO_REMAPPING_TABLE_REVISION_05,
> + EFI_ACPI_IO_REMAPPING_TABLE_REVISION_06,
> // Minimum supported ACPI Table Revision
> EFI_ACPI_IO_REMAPPING_TABLE_REVISION_00,
> // Creator ID
[-- Attachment #2: Type: text/html, Size: 7637 bytes --]
prev parent reply other threads:[~2023-02-06 10:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 18:40 [PATCH 1/2] DynamicTablesPkg: IORT generator updates for Rev E.e spec Name
2023-01-25 18:40 ` [PATCH 2/2] MdePkg:IORT header update for IORT " Name
2023-01-29 5:59 ` 回复: " gaoliming
2023-02-03 18:47 ` Swatisri Kantamsetti
2023-02-10 5:26 ` 回复: [edk2-devel] " gaoliming
2023-02-06 10:34 ` Sami Mujawar
2023-02-03 16:40 ` [PATCH 1/2] DynamicTablesPkg: IORT generator updates for " PierreGondois
2023-02-06 10:38 ` Sami Mujawar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf07f8c9-4c02-4502-0aa6-30d6cb220120@arm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox