From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (EUR04-DB3-obe.outbound.protection.outlook.com [40.107.6.70]) by mx.groups.io with SMTP id smtpd.web09.3744.1661290151856347519 for ; Tue, 23 Aug 2022 14:29:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@armh.onmicrosoft.com header.s=selector2-armh-onmicrosoft-com header.b=HkVMijTl; spf=pass (domain: arm.com, ip: 40.107.6.70, mailfrom: rohit.mathew@arm.com) ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=B8VEjfUvhLSlmd4ZIoD7JjUwT60wnnfd1cq1Zb2yYHeAlaogdw8+OvS7lVmgHn6Zhh1ecmh7KqFcrt1YOZsZBCSs3n7BflDgf7UzYO4Q/jRJrmJHqaXhb1TYV8GPWu50LleDmIICtSareYmkOQ1Yu+vzEIm5qhhIeEeOKTKAZe1xyxdlyPDp6fj06n64HT34DRD4gqPjPOG3umk32LAcViK0kv1NJS07lBdYq6bFiMJawzfMquaYW2UCBaM6G8RDeexesylc/+F49864YhLKy6QBKg9hRxHB5FNJ1g5tbJ8BRTZWpLOOB4IHXtTMRIZnYA8a65xUhLp7x1xyku3pPQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+LRpRJKl7l3z2OCy59WeGtCeZtj+6IYVDt1XhNBJ3q0=; b=nvA/uMaQhPavtIpXgv4Ce9xzgliRijnIWfxH8G/0hu+eniLQQssYuOkqL3Z5ZmOS4Gm+wR3F1sGdWnjmpHzxXHNPzt029dPDW9jEeBwPMCQ5D+WizU4pl7U7udQTB55csrVoXMwT5h2MNjYk6mLK7L5hhkxUJGuBEQM5lLgEKBpYHegYdNrssQowoRrjYLOKbhTuHjsLeS2jk/hakCzrVDfwfXnZpa4G7kUrbB8oNfRKdYyavLJubamY8bpEicpQRLjxBfMUDjclIBd7td0yztn7+jI8Xav0bvfFEoYm4OnPogpmwmry4pE7tA4ucoC/7+iSCFUXplNAO42dPLzZGQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=edk2.groups.io smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+LRpRJKl7l3z2OCy59WeGtCeZtj+6IYVDt1XhNBJ3q0=; b=HkVMijTlaWZ4fKLGd/yGkCvIfZ4hhkasNofKEmYOCrX4LB/iMcY+JcRGq5CwVZyGEZn3zzojzFKaRSy3SOx2G0AwA/h5jylNI+1LyN/KvJsl7xS4eFsmIEt+BeM3Hp7MY+n5eDq6AWZfGGU3BI4I/lAudPe4XDaLo+cTQVCKnAc= Received: from AS9PR06CA0603.eurprd06.prod.outlook.com (2603:10a6:20b:46e::12) by DU0PR08MB7993.eurprd08.prod.outlook.com (2603:10a6:10:3e0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.15; Tue, 23 Aug 2022 21:29:08 +0000 Received: from VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:46e:cafe::f7) by AS9PR06CA0603.outlook.office365.com (2603:10a6:20b:46e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.21 via Frontend Transport; Tue, 23 Aug 2022 21:29:08 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT007.mail.protection.outlook.com (10.152.18.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.15 via Frontend Transport; Tue, 23 Aug 2022 21:29:07 +0000 Received: ("Tessian outbound 73dd6a25223d:v123"); Tue, 23 Aug 2022 21:29:07 +0000 X-CR-MTA-TID: 64aa7808 Received: from 1b26a48739d6.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F962D4DB-AB46-46AE-8337-7DFAEF77135D.1; Tue, 23 Aug 2022 21:28:56 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1b26a48739d6.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 23 Aug 2022 21:28:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XGfLhvjNsYoASbl6SQU8cywN/ksSUypR6sdmZaa59dgH3gFzhHxBPcgjuGfp4MGO9kw+uZ3J0PrxExza6CqRCO2vQcjg5YTmaPV9vUy5LQ9EICSVWzCt7AT+QnIIGTEkn/H9NKFbL5GzxLAN7a7K0+k0i9jmDwGN1W/BLnesRdnrHs+YNfJfLDg9tu5tHgPYngS2p6vSa48dBEsr+GZ9eloxxkxNo3fyJ2jJNL4KaS1hrk4wkuvVhr9jIueQO7FTPH/Ftbxj4+7ObscMbPa02+B79D2C9yk0zEiIdazAhQMN1HE4L9l+ZEeCkC1HmIU2ojaw1pztO8NsPV8gACSlWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+LRpRJKl7l3z2OCy59WeGtCeZtj+6IYVDt1XhNBJ3q0=; b=UTTCQjRrm6rLPhWxpbQVGRgrPtA/JAaFAFHTlIMrC6lb7KdBsiEb1ojiGucC5vX3vTv1rj+XkeLhGLOPpY+r+eI9vZ6KNvSdKUn0PvFXMI1nRPdYxxFQV+qRbb6jExqEZTJYvHEYCebKpRITJQg3SSvKUvMVNHvtyDiWdAGucRrdR1cAdCNC04GXEOpAtbkR/z/FlVE35DvrBtr0LJGSBCmWmqy2OPhUGiYguQi17RFu8obfMa7jewbWvPw2pQQdrizwE1wCzq4osBXJ658bBC7YmQuBiDk9672rEY77GwQ/EBu/+tbZkHHcjrdIniRNhAdOdTo7sb2xIYi01SEPgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+LRpRJKl7l3z2OCy59WeGtCeZtj+6IYVDt1XhNBJ3q0=; b=HkVMijTlaWZ4fKLGd/yGkCvIfZ4hhkasNofKEmYOCrX4LB/iMcY+JcRGq5CwVZyGEZn3zzojzFKaRSy3SOx2G0AwA/h5jylNI+1LyN/KvJsl7xS4eFsmIEt+BeM3Hp7MY+n5eDq6AWZfGGU3BI4I/lAudPe4XDaLo+cTQVCKnAc= Received: from AM6PR08MB3783.eurprd08.prod.outlook.com (2603:10a6:20b:8a::13) by DBBPR08MB4631.eurprd08.prod.outlook.com (2603:10a6:10:df::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.19; Tue, 23 Aug 2022 21:28:50 +0000 Received: from AM6PR08MB3783.eurprd08.prod.outlook.com ([fe80::2012:400b:f926:7801]) by AM6PR08MB3783.eurprd08.prod.outlook.com ([fe80::2012:400b:f926:7801%6]) with mapi id 15.20.5546.024; Tue, 23 Aug 2022 21:28:50 +0000 From: "Rohit Mathew" To: Andrew Fish , "devel@edk2.groups.io" , Swatisri Kantamsetti CC: Sami Mujawar , Alexei Fedorov , Mike Kinney , "gaoliming@byosoft.com.cn" , "zhiguang.liu@intel.com" , Thomas Abraham , Thanu Rangarajan , nd Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table Thread-Topic: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table Thread-Index: AQHYsb2ZZQdbvCQTB0Go+zl5ZNUfvK21LnkwgAfG2oCAAAtPsA== Date: Tue, 23 Aug 2022 21:28:50 +0000 Message-ID: References: <7f8a5c9bbdf1a1f01c6fc822fa298067d280079a.1660667637.git.swatisrik@nvidia.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 72441F4A2C68AE4F825C07D1CD41C5C0.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: 54b8dcd0-8d88-4c34-0973-08da854e82eb x-ms-traffictypediagnostic: DBBPR08MB4631:EE_|VE1EUR03FT007:EE_|DU0PR08MB7993:EE_ x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 0uBC4NdnbDf59Kxy6TyYItUgI4qVm8+gWv0suDtzoFCfuNY5htF1BdGe5l7G83Bz9UsAQdgfAk3vCmZLx4V6cLLb+3cIQeDkY91awOrd9seYSOM3I+Gao3/PbAtpoIFsjX2qvLN2bxhMD5ronjMxhLjCsgqaHUwk/3/p3e5hKxjsGMCgNATc+TQ7zoCGbmz0qBKlHzieOA74aJH/WU67u4OCz4eam6ocT+BI51KdK5QtHd7ZmDpYhkh7QahA7yiVxkunC59EZkk8QWSeCvs33UAzZseRVAGFJ3kwk01c0/gjo7DsMmM82zTtpS4DyUrrqs9cYzDQtktQcUh1kppmWSdLju6PYvvwcpgXlbSMLYtCLhLmiPmKAQQjGhokKPYZtGjG2P+9zCLaD8bSqmKbg1w72bvxYDz6qlbtywdqcvG3uLz5iBO9b2433Law7LaHfrY07a8lOOJcIVmQnZvVSbn+4B6hkn9y0KMH836juzpL4lbeWUp0MO6OoE+CRZpRUc5xxXlmkeG29LHBiaj1H+hKuaA9aBpVN2RA+eaDdVgaznvw7wIpmncX4KszaatJC7N+1Mx3YAGhsMr0bVcpHYKw+8s1uWOdLT4XEf6hu0pq6Zha7LUGImLlSfEV7m83yBd+am3A0N3YcLESn/XCmLvyykfgfM4dHOA1Z+6UmhXJyiGplTewrVO+PxE2+vfx7RaWq3i+f5TLTeI/p/GQMHIqK/2j2dz0WM0FxVazEtlKipGOScTBm0nfhmzggqWTVo4zlXHd+Nhna1Q/8vP9+wQ9mo3LhsxPsnJZXDlriPUWxYgZccCc2VTDvIIawSMNcP2AdK6WuwrhM40ePb+D9Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM6PR08MB3783.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(39860400002)(346002)(136003)(396003)(376002)(53546011)(55236004)(26005)(83380400001)(7696005)(6506007)(9686003)(33656002)(2906002)(186003)(166002)(86362001)(38070700005)(55016003)(966005)(54906003)(5660300002)(66556008)(122000001)(8676002)(4326008)(66946007)(66476007)(64756008)(66446008)(41300700001)(76116006)(316002)(110136005)(8936002)(9326002)(38100700002)(478600001)(52536014)(71200400001);DIR:OUT;SFP:1101; MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4631 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Return-Path: Rohit.Mathew@arm.com X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ed7a104c-ff33-428f-509a-08da854e7897 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DeCGfkJ4wIfZBGhi342FCC2CB7xPCLUahj8mSjCdZzZlezSeNWF3LCsR0w+DPlxaHakWIB7XwMT2b0WLbtD9EE5A9LhS/H+NrZdRIk51rnRgilD4+Q++FU46rsQPbvBw4JPNIfD9vYS//tuGTTGcWuxp11+A6pHigMFmtmy2DVFVGR9NJzHBRhvXnqACU7C/JZ/rrzXWS66pKniUf0427sajJhjSp6Dl7JFPoXCpt303y8vVz9QAhnxhUPEodpQAQa3nZ2vkLH7ZmUvAb7sDUoeNRIo5cn1ZxarbwPHUSsJiuGXvX1/v+k76kaxPhTLoWEHBXN0oJ4ogHbHWWQTppDtun+jHoQM9KYikYeegaY4uxkjgov3czDlmdO8zs+y9HmJAoBKcrXIBvL62iiMbOeL8K3FMoGydOlGm9EpqsftAKzs45pK85LK/3zF8MWc/dHTmwXmV2VLdfwoTuJTydAAOMwXGTeUwdOTAt+KcvAUBe0qzpBB289WcnxCiOSHIHMRY9PAdLhHNchYNb4OViaFZ/z2mBxTq7N1Y8ZT/WPPhQd3uJNt8FGubatg7xZtXNJUvwRG9B+wiTmhGLa1qs9jqYqR+0LcZUR1PUFNjcCF3srTZJmA3CyhSMKr718Ejjb3Dhaec26U5YXJAL9IajHMT41gl8WVAGZ7qoAMoMudHaFXydv117Fj19pkF1PjeUgZjWcNkCzQ6o1fKuN7g7xGXN7iPbiYQX138lEFZ9s9FheIiFwZZGfkOWCZFLajqLgT8emMcQnta0fF/lUWHp3mXPl0ce5Nj3W9btkazr0LmAwfcGi7WmKQXAYUYY5lmoeDamGeTIStuXHWuIL5mgg== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230016)(4636009)(39860400002)(396003)(376002)(346002)(136003)(40470700004)(46966006)(36840700001)(70206006)(70586007)(8676002)(4326008)(336012)(186003)(36860700001)(47076005)(8936002)(9326002)(52536014)(2906002)(30864003)(54906003)(316002)(33656002)(5660300002)(110136005)(19627235002)(478600001)(966005)(26005)(6506007)(86362001)(55016003)(53546011)(7696005)(9686003)(82310400005)(40480700001)(41300700001)(166002)(81166007)(40460700003)(356005)(83380400001)(82740400003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2022 21:29:07.5325 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 54b8dcd0-8d88-4c34-0973-08da854e82eb X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7993 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM6PR08MB37834E7331D7A6D40F85AE6A8F709AM6PR08MB3783eurp_" --_000_AM6PR08MB37834E7331D7A6D40F85AE6A8F709AM6PR08MB3783eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew, From: Andrew Fish Sent: 23 August 2022 21:11 To: devel@edk2.groups.io; Rohit Mathew Cc: username@nvidia.com; Sami Mujawar ; Alexei Fedoro= v ; Mike Kinney ; gaoli= ming@byosoft.com.cn; zhiguang.liu@intel.com; Swatisri Kantamsetti ; Thomas Abraham ; Thanu Rangarajan ; nd Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table On Aug 19, 2022, at 1:26 AM, Rohit Mathew > wrote: Hi Swatisri, Thanks for the patch. Please find my comments inline marked [Rohit] - -----Original Message----- From: devel@edk2.groups.io > On Behalf Of Name via groups.io Sent: 16 August 2022 21:18 To: devel@edk2.groups.io; Sami Mujawar >; Alexei Fedorov >; mic= hael.d.kinney@intel.com; gaoliming@byosoft.com.cn; zhiguang.liu@int= el.com Cc: Swatisri Kantamsetti = > Subject: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table From: Swatisri Kantamsetti > Added MPAM table header, MSC and Resource Node info structures Signed-off-by: Swatisri Kantamsetti > --- MdePkg/Include/IndustryStandard/Acpi64.h | 5 ++ MdePkg/Include/IndustryStandard/Mpam.h | 69 ++++++++++++++++++++++++ 2 files changed, 74 insertions(+) create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h b/MdePkg/Include/IndustryStandard/Acpi64.h index fe5ebfac2b..e54f631186 100644 --- a/MdePkg/Include/IndustryStandard/Acpi64.h +++ b/MdePkg/Include/IndustryStandard/Acpi64.h @@ -2952,6 +2952,11 @@ typedef struct { /// #define EFI_ACPI_6_4_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SI GNATURE SIGNATURE_32('P', 'P', 'T', 'T') +/// +/// "MPAM" Memory System Resource Partitioning And Monitoring Table /// +#define +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI NG_TABLE_STRUC +TURE_SIGNATURE SIGNATURE_32('M', 'P', 'A', 'M') + /// /// "PSDT" Persistent System Description Table /// diff --git a/MdePkg/Include/IndustryStandard/Mpam.h b/MdePkg/Include/IndustryStandard/Mpam.h new file mode 100644 index 0000000000..e0f75f0114 --- /dev/null +++ b/MdePkg/Include/IndustryStandard/Mpam.h @@ -0,0 +1,69 @@ +/** @file + ACPI Memory System Resource Partitioning And Monitoring (MPAM) + as specified in ARM spec DEN0065 + + Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved. + Copyright (c) 2022, ARM Limited. All rights reserved. + SPDX-License-Identifier: BSD-2-Clause-Patent **/ + +#ifndef _MPAM_H_ +#define _MPAM_H_ + +#pragma pack(1) + +/// +/// Memory System Resource Partitioning and Monitoring Table (MPAM) /// +typedef struct { + EFI_ACPI_DESCRIPTION_HEADER Header; + UINT32 NumNodes; + UINT32 NodeOffset; + UINT32 Reserved; +} +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI NG_TABLE_HEADE +R; [Rohit] Shouldn't the header be followed by MSC node body type as defined i= n MPAM ACPI 1.0, section 2, table 3 - The MPAM table and section 2.1, table= 4 - MSC Node body? + +/// +/// MPAM Revision (as defined in ACPI 6.4 spec.) /// #define +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI NG_TABLE_REVIS +ION 0x01 + +/// +/// Memory System Controller Node Structure /// + +typedef struct { + UINT16 Length; + UINT16 Reserved; + UINT32 Identifier; + UINT64 BaseAddress; + UINT32 MmioSize; + UINT32 OverflowInterrupt; + UINT32 OverflowInterruptFlags; [Rohit] Would it be better to have a type (possibly bitfield struct) instea= d of a plain UINT32 for Flags? (MPAM ACPI 1.0, section 2.1.1, table 5 - Int= errupt flags) Probably better NOT to use bitfields in APIs that are produced and consumed= by different worlds. While the the UEFI does speak to the bit order of or = a bitfield the rules around packing of bitfields is compiler defined. I just saw a bug last week with bitfield compatibility that was introduced = by clang fixing its -mms-bitfields implementation. The GCC rules for packin= g bitfields is different than VC++ so that is why the compiler flag -mms-bi= tfields exists in the 1st place . A clang -mms-bitfields bug got fixed and= it broke the code as the extra padding required by VC++ got added to the b= itfield. [Rohit] Thanks for bringing this point. I think, this type could be left un= touched in that case. Thanks, Andrew Fish + UINT32 Reserved1; + UINT32 OverflowInterruptAff; + UINT32 ErrorInterrupt; + UINT32 ErrorInterruptFlags; [Rohit ] Same comment as before above. + UINT32 Reserved2; + UINT32 ErrorInterruptAff; + UINT32 MaxNRdyUsec; + UINT64 LinkedDeviceHwId; + UINT32 LinkedDeviceInstanceHwId; + UINT32 NumResourceNodes; +} EFI_ACPI_6_4_MPAM_MSC_NODE; + +/// +/// Resource Node Structure +/// + +typedef struct { + UINT32 Identifier; + UINT8 RisIndex; + UINT16 Reserved1; + UINT8 LocatorType; + UINT64 Locator; [Rohit ] Shouldn't " Locator " field be 12 bytes in size, possibly a separa= te type? (MPAM ACPI 1.0, section 2.2, table 7 - Resource node and section 2= .3.2 table 10 - locator descriptor) + UINT32 NumFuncDep; +} EFI_ACPI_6_4_MPAM_RESOURCE_NODE; [Rohit] Since "NumFuncDep" field is part of EFI_ACPI_6_4_MPAM_RESOURCE_NODE= type and this could be non-zero, should we also need the type for function= al dependency descriptors? (MPAM ACPI 1.0, section 2.2.1, table 8 - Functio= nal dependency descriptor) [Rohit] Also, could some of the commonly used macros be added to this heade= r, please? (location types, MPAM interrupt mode, interrupt types, affinity = type, etc) + +#pragma pack() + +#endif -- 2.17.1 Regards, Rohit --_000_AM6PR08MB37834E7331D7A6D40F85AE6A8F709AM6PR08MB3783eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

From: Andrew Fish <afish@apple.com> Sent: 23 August 2022 21:11
To: devel@edk2.groups.io; Rohit Mathew <Rohit.Mathew@arm.com><= br> Cc: username@nvidia.com; Sami Mujawar <Sami.Mujawar@arm.com>; = Alexei Fedorov <Alexei.Fedorov@arm.com>; Mike Kinney <michael.d.ki= nney@intel.com>; gaoliming@byosoft.com.cn; zhiguang.liu@intel.com; Swati= sri Kantamsetti <swatisrik@nvidia.com>; Thomas Abraham <thomas.abraham@arm.com>; Thanu Rangarajan <Thanu.Rangarajan@arm.= com>; nd <nd@arm.com>
Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI= Table

 

 



On Aug 19, 2022, at 1:26 AM, Rohit Mathew <rohit.mathew@arm.com> wrote:<= /o:p>

 

Hi Swatisri,

Thanks for the patch. Please find my comments inline marked [Rohit] -


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Name
via groups.io
Sent: 16 August 2022 21:18
To: devel@edk2.groups.io; Sami Mujawar <Sami.Mujawar@= arm.com>;
Alexei Fedorov <Alexe= i.Fedorov@arm.com>;&n= bsp;michael.d= .kinney@intel.com;
gaoliming@byosoft.com.= cn; <= a href=3D"mailto:zhiguang.liu@intel.com">zhiguang.liu@intel.com
Cc: Swatisri Kantamsetti <swatisrik@nvidia.com>
Subject: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table

From: Swatisri Kantamsetti <swatisrik@nvidia.com>

Added MPAM table header, MSC and Resource Node info structures

Signed-off-by: Swatisri Kantamsetti <swatisrik@nvidia.com>
---
MdePkg/Include/IndustryStandard/Acpi64.h |  5 ++
MdePkg/Include/IndustryStandard/Mpam.h   | 69
++++++++++++++++++++++++
2 files changed, 74 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h

diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
b/MdePkg/Include/IndustryStandard/Acpi64.h
index fe5ebfac2b..e54f631186 100644
--- a/MdePkg/Include/IndustryStandard/Acpi64.h
+++ b/MdePkg/Include/IndustryStandard/Acpi64.h
@@ -2952,6 +2952,11 @@ typedef struct {
///
#define
EFI_ACPI_6_4_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SI
GNATURE  SIGNATURE_32('P', 'P', 'T', 'T')

+///
+/// "MPAM" Memory System Resource Partitioning And Monitoring Ta= ble
///
+#define
+EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
NG_TABLE_STRUC
+TURE_SIGNATURE  SIGNATURE_32('M', 'P', 'A', 'M')
+
///
/// "PSDT" Persistent System Description Table  /// diff --g= it
a/MdePkg/Include/IndustryStandard/Mpam.h
b/MdePkg/Include/IndustryStandard/Mpam.h
new file mode 100644
index 0000000000..e0f75f0114
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Mpam.h
@@ -0,0 +1,69 @@
+/** @file
+  ACPI Memory System Resource Partitioning And Monitoring (MPAM)
+  as specified in ARM spec DEN0065
+
+  Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
+  Copyright (c) 2022, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent **/
+
+#ifndef _MPAM_H_
+#define _MPAM_H_
+
+#pragma pack(1)
+
+///
+/// Memory System Resource Partitioning and Monitoring Table (MPAM)
///
+typedef struct {
+  EFI_ACPI_DESCRIPTION_HEADER    Header;
+  UINT32           =             &nb= sp; NumNodes;
+  UINT32           =             &nb= sp; NodeOffset;
+  UINT32           =             &nb= sp; Reserved;
+}
+EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
NG_TABLE_HEADE
+R;


[Rohit] Shouldn't the header be followed by MSC node body type as defined i= n MPAM ACPI 1.0, section 2, table 3 - The MPAM table and section 2.1, table= 4 - MSC Node body?


+
+///
+/// MPAM Revision (as defined in ACPI 6.4 spec.) /// #define
+EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
NG_TABLE_REVIS
+ION  0x01
+
+///
+/// Memory System Controller Node Structure ///
+
+typedef struct {
+  UINT16    Length;
+  UINT16    Reserved;
+  UINT32    Identifier;
+  UINT64    BaseAddress;
+  UINT32    MmioSize;
+  UINT32    OverflowInterrupt;
+  UINT32    OverflowInterruptFlags;<= /p>


[Rohit] Would it be better to have a type (possibly bitfield struct) instea= d of a plain UINT32 for Flags? (MPAM ACPI 1.0, section 2.1.1, table 5 - Int= errupt flags)

 

Probably better NOT to use bitfields in APIs that ar= e produced and consumed by different worlds. While the the UEFI does speak = to the bit order of or a bitfield the rules around packing of bitfields is = compiler defined.

 

I just saw a bug last week with bitfield compatibili= ty that was introduced by clang fixing its -mms-bitfields implementati= on. The GCC rules for packing bitfields is different than VC++ so that is w= hy the compiler flag -mms-bitfields exists in the 1st place . A clang -mms-bitfields bug  got fixed and it broke= the code as the extra padding required by VC++ got added to the bitfield.&= nbsp;

 

[Rohit] Thanks for bringing this point. I think, thi= s type could be left untouched in that case.

 

Thanks,

 

Andrew Fish



+  UINT32    Reserved1;
+  UINT32    OverflowInterruptAff;
+  UINT32    ErrorInterrupt;
+  UINT32    ErrorInterruptFlags;


[Rohit ] Same comment as before above.


+  UINT32    Reserved2;
+  UINT32    ErrorInterruptAff;
+  UINT32    MaxNRdyUsec;
+  UINT64    LinkedDeviceHwId;
+  UINT32    LinkedDeviceInstanceHwId;
+  UINT32    NumResourceNodes;
+} EFI_ACPI_6_4_MPAM_MSC_NODE;
+
+///
+/// Resource Node Structure
+///
+
+typedef struct {
+  UINT32    Identifier;
+  UINT8     RisIndex;
+  UINT16    Reserved1;
+  UINT8     LocatorType;
+  UINT64    Locator;


[Rohit ] Shouldn't " Locator " field be 12 bytes in size, possibl= y a separate type? (MPAM ACPI 1.0, section 2.2, table 7 - Resource node and= section 2.3.2 table 10 - locator descriptor)


+  UINT32    NumFuncDep;
+} EFI_ACPI_6_4_MPAM_RESOURCE_NODE;


[Rohit] Since "NumFuncDep" field is part of EFI_ACPI_6_4_MPAM_RES= OURCE_NODE type and this could be non-zero, should we also need the type fo= r functional dependency descriptors? (MPAM ACPI 1.0, section 2.2.1, table 8= - Functional dependency descriptor)

[Rohit] Also, could some of the commonly used macros be added to this heade= r, please? (location types, MPAM interrupt mode, interrupt types, affinity = type, etc)


+
+#pragma pack()
+
+#endif
--
2.17.1





Regards,
Rohit



 

--_000_AM6PR08MB37834E7331D7A6D40F85AE6A8F709AM6PR08MB3783eurp_--