From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 6FFDC740041 for ; Fri, 16 Aug 2024 15:07:13 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=VOtyUhlmkc6SDNjp6Pi4FJMNoQLUf5RjJ1Zjr5slv7o=; c=relaxed/simple; d=groups.io; h=From:To:CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References:In-Reply-To:Accept-Language:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type; s=20240206; t=1723820833; v=1; b=tHsZgJZOov5jlaugJHEdzpZi9W0A/mm4iyAH0aI0aK9rnTvrn78NJKhFeaKn5oGojY8ZvSSB UWHSDH1UUwqafe7PBILHaW4nZ/GhiQHXW/XzzcCkMQdIDix9jggJkkTY89yaglC3+0T+fiihr12 z6ZRAG2w0MK4IdqaM+H64JQp1m84t073VI/jlfdnEsOSrEXNSps6zocT6uXn0Lg8jo+kPvr84Ca /ZSO24E1VOBmUTt5SAoamNk4+InQiL8Ze+NgVcfRDfgFEg0cSJCv55Txs0eRJ5tVFBAtajpAt00 0IqYGGQLgGEnoPOPyuP5SgCfV+UQNZwUsU5fRvdUWnBuw== X-Received: by 127.0.0.2 with SMTP id IB7IYY7687511xD2FpTJ7bGx; Fri, 16 Aug 2024 08:07:12 -0700 X-Received: from NAM12-MW2-obe.outbound.protection.outlook.com (NAM12-MW2-obe.outbound.protection.outlook.com [40.107.244.57]) by mx.groups.io with SMTP id smtpd.web11.150205.1723820830931602928 for ; Fri, 16 Aug 2024 08:07:11 -0700 X-Received: from SJ0PR12MB6989.namprd12.prod.outlook.com (2603:10b6:a03:448::16) by SA3PR12MB9197.namprd12.prod.outlook.com (2603:10b6:806:39e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.19; Fri, 16 Aug 2024 15:07:00 +0000 X-Received: from SJ0PR12MB6989.namprd12.prod.outlook.com ([fe80::494a:7285:e1eb:1424]) by SJ0PR12MB6989.namprd12.prod.outlook.com ([fe80::494a:7285:e1eb:1424%3]) with mapi id 15.20.7875.016; Fri, 16 Aug 2024 15:06:59 +0000 From: "Jeshua Smith via groups.io" To: Sami Mujawar , "rfc@edk2.groups.io" , "devel@edk2.groups.io" CC: Ard Biesheuvel , Leif Lindholm , Pierre Gondois , Yeo Reum Yun , Varshit Pandya , nd Subject: Re: [edk2-devel] DynamicTablesPkg: Keeping AcpiProcessorId in PPTT and _UID in SSDT in sync? Thread-Topic: DynamicTablesPkg: Keeping AcpiProcessorId in PPTT and _UID in SSDT in sync? Thread-Index: AdruaBkG9HjMkRd4TliQETBJQnZrsQBfTI6AAAEkMhA= Date: Fri, 16 Aug 2024 15:06:59 +0000 Message-ID: References: <33462389-F8DF-4451-B519-93BBA3AA826A@arm.com> In-Reply-To: <33462389-F8DF-4451-B519-93BBA3AA826A@arm.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR12MB6989:EE_|SA3PR12MB9197:EE_ x-ms-office365-filtering-correlation-id: 34f6fc08-c8a4-4b54-07d2-08dcbe0513f4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam-message-info: =?us-ascii?Q?FPxhdzj0W6k3Qr8N6R3pG65EfssvnDMM3na8RpFweZ8O0h5KuV0HqNuKRfZX?= =?us-ascii?Q?/OSv7qGX13D7NoE2N5VFM+KDn8TFBv2m3mbPo0cPCh29YMjcD2X5Tr7L22q/?= =?us-ascii?Q?HzTKJiJfuMD0yoXTmiaNRpGJCnzPNKxMkoNh1ztC98/2I8SMyQ8DhrTu0bhZ?= =?us-ascii?Q?PgBv/GpY8z3LWG3U9w4cKhls+tPEzX9XoWxfGDzCVRQg8HAg41VSpe9qQWa4?= =?us-ascii?Q?RuB5gICw342RKyaIdj3GtjjsJH8eHJOTXZO0LbztuJHbch9v6QfWEYAildAp?= =?us-ascii?Q?CVB9A2XIQxaEPn02DUsC9we1uywZzlBOQN53r1ECt/o84YkBztPgT75oBMOk?= =?us-ascii?Q?J/3T8xUXUUwsjSweGvsYvhYqLRdClrUt1xMPPwh4yVrZ7MPqVCr3OjkyG2Nt?= =?us-ascii?Q?6UBDnphLKLYxinl1EkPBwfN7B7VwLfzMHDQ2s0Lb2rdl/iYxaRBrAEy+ECmU?= =?us-ascii?Q?IKgJLl9ZpYCzpPh7TIsugja4wNBfnrH7ZqmwL84eqAn8+gJiCdvPJaDYKQua?= =?us-ascii?Q?KzVY7ClVGQSbe0POu4uvxAD30JnqqSMogcl0ay4TVc1FlhPAAnS6OWWxfXmP?= =?us-ascii?Q?kmhPtxk2rSHzmkGZGvPfLgzvk/elHcYhOOwwy+C1R/Olkg9+Q4zO0dmOOMIz?= =?us-ascii?Q?g/RR00q69NM/9EvPEJrodkMysvOJlSRJc1K/QlE7WHOaLpgcliCaNnSK7xmv?= =?us-ascii?Q?V12aLC8ZvP1OQhWXlSkJFWX/nUXYnFajXmpckroQIYOnW7XWI74691thYgda?= =?us-ascii?Q?m9UMCP1zwEz00xdbK+4nICkWFO9pGanZhGONZe509z4xlum+ZatsOUGdewqa?= =?us-ascii?Q?cLRO26AxCJuFaVKsx9cpwySO0uhTzCiIm/vwER6hW4+DwezTof2vH8wxn9t8?= =?us-ascii?Q?uJfV9fDIudYHxssd1l8h1weY1PlJZoV9e+jmwZDeYBAmK4Va20u+zhJf2XGU?= =?us-ascii?Q?q7viLA6zPPvx03Lm5F2RdBOtoQVFeWHb30+/rZSmps74ER41lOrvGugiF3b2?= =?us-ascii?Q?efdhFBPz8IMgCqBgaXjs6MvXIslO+c1h1FIkHuxErWonu8ZnSkwGgJgCfEUi?= =?us-ascii?Q?cJM1PgFXP1QzuT0XVyrOT2B+aXwkOtTN89LAMO5pgE/Um9Z33VR8gz4UrWic?= =?us-ascii?Q?+ksDZnY9fANd9jlx5VsUyuv0V8i/ZX+lsjeHtaBXdKGnJNu5uB4ttfg1qGYP?= =?us-ascii?Q?siyFqWrWO68aYQRuXy4JZ+fGcnJtGqMUsgPge/BBAJ5erBBJeKFg6U/crW1B?= =?us-ascii?Q?ymDL7JtRZ2NEzOFjdFrluTHZb58xIoAsFetomIkowbp6/EmhnWYq1HQSWJwB?= =?us-ascii?Q?dNRy+mSVtdm3rRcbFj8Vfv53qzFWhT9Els314CtiS7N+QO9234ddepsFhYQS?= =?us-ascii?Q?coN9ABE=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?J26o9/mHfekgG2n4O/mDZpNjXfmryizMu9io1q2vniFv9lL0emwR7f4nfRGN?= =?us-ascii?Q?fD5W2PI6X4ph/8W5LZBBtVnpsOV0TzylXkbMtyzZD4FMWskfP76ox4hTKmLX?= =?us-ascii?Q?ld9z/o9C6aNkTWI+dTHuZ8rXEatv5FgqIZLGsv/wfRZGQZX12XaB33uipnBP?= =?us-ascii?Q?Toa7KEybFduIa48MM1yjsZXgcTeYLpZHHmFsWSPqIqPCC3whaliH3VjTMJY4?= =?us-ascii?Q?vGD9aZ17Ytr3fXd+zhnFHghoYcz42HToQ2ibTp4K0vooqMgIIPkE635zSMec?= =?us-ascii?Q?9rldpHVH5n9BDNshh3wjLwFAhYzxWdC/i9hyuSN9Gto/un3b9wSA4lTbOddz?= =?us-ascii?Q?+5O333/0dLSX4PCPWFgR4th7H2LXOpies5lS12+b2wmAZmRtywtwZbft/tC0?= =?us-ascii?Q?AmoxKsDJXoezVoLepb1n9Rf3bUXH+dhgp8BGhxYOs2xe/qOQkFb9oJlwLncN?= =?us-ascii?Q?cPzJ3jiEz5rfkcQjguXhS5A3SsKDRHUAzTy18/tEfDCPdhylddozJY7CWuPI?= =?us-ascii?Q?t1SEE5Rx4oBJXSRWhObjOEW18xWkC7eICsWRneoNELpICbT+uAs4W9m2yMPn?= =?us-ascii?Q?GmVl5PQrUyaPcAp7NG4TeA7PA1jChe+QpZMXYGSoOEnIKQl6D/lbdIEibzFH?= =?us-ascii?Q?S4aBq2Nq0Q1k0m9qpTnXL+BU1vXXrfMfg7EB3h3y2qRx1nJ+QdlEtS596gkD?= =?us-ascii?Q?SeSKjajN8E75D9M6f3GdOaTtvW1C7Q4zAwbBGMRVp7UQf/DF0ixCy4Qxffg7?= =?us-ascii?Q?fuTogtVoMVbRQLcQlgmSI+6f5TYOqvtJ2sT0lEQUMFvbMu1b7F5A46WvKvo+?= =?us-ascii?Q?6/MXYtGLfpIbn6A0UGBwSuMYO5TIo6bc36zoQgHfLTynlWSlE+Dojiq+GXZo?= =?us-ascii?Q?RqbNLFe6oHynkpls4B2FN/DbrVfygt8f3y00M+nbles4kCtW15ltQqQy5Apn?= =?us-ascii?Q?YmZ2a/bkZoOzgLR6p3q+3/wijZuDJaSNKFAtSt883mWL0hM5CSDtUsyGKpjp?= =?us-ascii?Q?4nWLPSmxkcSA9oah4fCMUNLRLSEwYQJxbU3u2csqp2EbyxvOWnFAS3uCORac?= =?us-ascii?Q?9tqj4rCAhub/FJsGrutKSWVTnEZLM/SVftIs3gwOTU5gmfwjgauK2ghpKmC5?= =?us-ascii?Q?n2WNRFBL7z0MVf1fHD+7W1fP/7odHVDKpqKSZzEJ239xLqVaik1uOq4JC5ci?= =?us-ascii?Q?zFsEVJKJRf0/8srVRAbLFazpLLVUKdR0G6dXh0HyqSgEW9EaG/MsF3SUkXiw?= =?us-ascii?Q?GJ0JGpx4yBNgPDwkr7OhHlqPveKS6FQdbeiV9wF4tU/XLrj+iUiakgKmfOea?= =?us-ascii?Q?R5d8Rzw02FUhah58zdIJmulncelw5gZvqNGYuwxOKdB0+wpkBUG04y8Y5xS8?= =?us-ascii?Q?g3NEvUtem07QNuORegD1E8NXiPA1Jk0es0UIMtWon9MLYVwHAkBkkexZDs3Q?= =?us-ascii?Q?UkMGIA0yc5RguJCtLRByO5tT86gqvBNHrBYBGiEi6ra1MAocbkIOXeb2v3ni?= =?us-ascii?Q?EflAiEVa6jqTAA1/a70rR7zcQWa7mVN+ifPUCsEIYHVHIfIDSpxryPlPtwhy?= =?us-ascii?Q?7u/Om0Gn0pMYqVVNUvlBcaDBZdYgDG6kofF1j9xM?= MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR12MB6989.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34f6fc08-c8a4-4b54-07d2-08dcbe0513f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2024 15:06:59.8268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jL0gcHQgovTMTVfg9xGsMk0RMf1pO66/NorAhYGACjoxjn/QWxNPhqhl9kbuKJqk0D53TXMWgIDJy8Puq37lzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9197 Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Fri, 16 Aug 2024 08:07:11 -0700 Resent-From: jeshuas@nvidia.com Reply-To: devel@edk2.groups.io,jeshuas@nvidia.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: Jpcj42oqVBwRAkeGeugHSVnRx7686176AA= Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_SJ0PR12MB69894999102C10896467677DDB812SJ0PR12MB6989namp_" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=tHsZgJZO; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --_000_SJ0PR12MB69894999102C10896467677DDB812SJ0PR12MB6989namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, thank you for the quick reply. That should be fine. Our implementation is currently using the Override method to take care of t= he ID generation so internally we are able to make progress without an offi= cial answer. Eventually we would like to use upstream fixes of course. The = Override method works for us because it means the ProcHierarchyInfo structu= re is our single source of truth that both table generators refer to. I jus= t didn't want to submit a patch that doesn't correctly support the auto-gen= erated ID method since I assume that wouldn't be accepted. ID generation and management is indeed an important but sometimes tricky pr= oblem. In my opinion the most important thing is to make sure that there is= a single source of truth that all other code consults, vs. trying to make = sure different pieces of code independently generate the same ID. From: Sami Mujawar Sent: Friday, August 16, 2024 7:05 AM To: Jeshua Smith ; rfc@edk2.groups.io; devel@edk2.group= s.io Cc: Ard Biesheuvel ; Leif Lindholm ; Pierre Gondois ; Yeo Reum Yun ; Varshit Pandya ; nd Subject: Re: DynamicTablesPkg: Keeping AcpiProcessorId in PPTT and _UID in = SSDT in sync? External email: Use caution opening links or attachments Hi Jeshua, Thank you for your email and for bringing up this concern for discussion on= the list. The ACPI ID is used at multiple places, and we need to investigate this in = detail and come up with a solution. Pierre has worked on most of the SSDT C= PU generator, but he is on leave until the end of next week. We had internally discussed few ideas some time back to solve a similar iss= ue. I think we need a generic solution for ID generation and management. Is it ok if we get back with our findings once Pierre is back, please? Regards, Sami Mujawar From: Jeshua Smith > Date: Wednesday 14 August 2024 at 17:46 To: "rfc@edk2.groups.io" > Cc: Ard Biesheuvel >, Leif Lindholm >, Pierre Gondois >, Sami Mujawar > Subject: DynamicTablesPkg: Keeping AcpiProcessorId in PPTT and _UID in SSDT= in sync? Currently the SSDT and PPTT generators in DynamicTablesPkg use the ProcHier= archyInfo structure to generate their ACPI tables. The current code for PPT= T will: 1. Set the AcpiProcessorId field in PPTT to 0 if the AcpiProcessorIdVali= d flag isn't set, OR 2. Throw an error if AcpiIdObjectToken is CM_NULL_TOKEN, OR 3. Set the AcpiProcessorId field in PPTT to the AcpiProcessorUid of the = object pointed to by AcpiIdObjectToken In practice (on ARM), this means that all PPTT nodes that reference an actu= al processor get their ID from their GIC and all PPTT nodes that are proces= sor containers have their ID forced to 0. If you try to set an ID for a pro= cessor container by setting the IdValid flag for the container it results i= n an error. Similarly, the SSDT node checker expects that all nodes that ha= ve the IdValid flag set also have their Leaf flag set and are leaf nodes; i= t will throw an error if any non-leaf node has the IdValid flag set. However, the PPTT spec says (5. ACPI Software Programming Model - ACPI Spec= ification 6.5 documentation (uefi.org)): ACPI Processor ID 4 12 If the processor structure represents an actual processor, this field must = match the value of ACPI processor ID field in the processor's entry in the = MADT. If the processor structure represents a group of associated processor= s, the structure might match a processor container in the name space. In th= at case this entry will match the value of the _UID method of the associate= d processor container. Where there is a match it must be represented. The f= lags field, described in Processor Structure Flags, includes a bit to descr= ibe whether the ACPI processor ID is valid. and the flag ACPI Processor ID valid 1 1 For non-leaf entries in the processor topology, the ACPI Processor ID entry= can relate to a Processor container in the namespace. The processor contai= ner will have a matching ID value returned through the _UID method. As not = every processor hierarchy node structure in PPTT may have a matching proces= sor container, this flag indicates whether the ACPI processor ID points to = valid entry. Where a valid entry is possible the ACPI Processor ID and _UID= method are mandatory. For leaf entries in PPTT that represent processors l= isted in MADT, the ACPI Processor ID must always be provided and this flag = must be set to 1. I read this to mean that the processor containers in PPTT are REQUIRED to h= ave a valid ID that matches the _UID of the corresponding container in SSDT= . To properly implement APMT support for a chip I'm working on I need to ensu= re that the PPTT has a valid (non-zero) ID for some processor containers in= order to match the requirements of the APMT table: ACPI for CoreSight Performance Monitoring Unit Architecture (arm.com) Processor affinity 4 48 Processor affinity for this PMU. This field must match the ACPI Processor I= D of the PPTT Type 0 structure that represents the processor or processor c= ontainer that this PMU is associated with. As a result, I'm working on a patch to enable the SSDT and PPTT generators = to generate a valid ID for processor container nodes, but I need some guida= nce. It isn't too hard to update the existing code to: 1. Allow non-leaf nodes to have the ID valid flag set 2. Generate the ID if the ID valid flag is set AND the ProcHierarchyInfo= structure specifies it explicitly via the OverrideNameUidEnabled flag and = its corresponding OverrideUid field. However, I'm not sure how to handle the case where ProcHierarchyInfo says a= valid ID is needed but one is not provided via Override. In this case SSDT= has some logic to auto-assign _UIDs, but the spec requires that PPTT set t= he AcpiProcessorId to that same value as those auto-assigned SSDT _UIDs. Ho= w should we guarantee that these auto-assigned values are in sync? Any guidance on how to handle this? Thanks, Jeshua Smith NVIDIA -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120360): https://edk2.groups.io/g/devel/message/120360 Mute This Topic: https://groups.io/mt/107931323/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --_000_SJ0PR12MB69894999102C10896467677DDB812SJ0PR12MB6989namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, thank you for the quick reply. That should be f= ine.

 

Our implementation is currently using the Override m= ethod to take care of the ID generation so internally we are able to make p= rogress without an official answer. Eventually we would like to use upstrea= m fixes of course. The Override method works for us because it means the ProcHierarchyInfo structure is our singl= e source of truth that both table generators refer to. I just didn’t = want to submit a patch that doesn’t correctly support the auto-genera= ted ID method since I assume that wouldn’t be accepted.

 

ID generation and management is indeed an important = but sometimes tricky problem. In my opinion the most important thing is to = make sure that there is a single source of truth that all other code consul= ts, vs. trying to make sure different pieces of code independently generate the same ID.

 

From: Sami Mujawar <Sami.Muja= war@arm.com>
Sent: Friday, August 16, 2024 7:05 AM
To: Jeshua Smith <jeshuas@nvidia.com>; rfc@edk2.groups.io; dev= el@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm = <quic_llindhol@quicinc.com>; Pierre Gondois <Pierre.Gondois@arm.co= m>; Yeo Reum Yun <YeoReum.Yun@arm.com>; Varshit Pandya <Varshit= .Pandya@arm.com>; nd <nd@arm.com>
Subject: Re: DynamicTablesPkg: Keeping AcpiProcessorId in PPTT and _= UID in SSDT in sync?

 

External email: Us= e caution opening links or attachments

 

Hi Jeshua,

 

Thank you for your email and fo= r bringing up this concern for discussion on the list.

 

The ACPI ID is used at multiple= places, and we need to investigate this in detail and come up with a solut= ion. Pierre has worked on most of the SSDT CPU generator, but he is on leav= e until the end of next week.

We had internally discussed few= ideas some time back to solve a similar issue. I think we need a generic s= olution for ID generation and management.

 

Is it ok if we get back with ou= r findings once Pierre is back, please?

 

Regards,

 

Sami Mujawar<= /p>

 

From: Jeshua Smith <jeshuas@nvidia.com>
Date: Wednesday 14 August 2024 at 17:46
To: "rfc@edk2.groups.io" <rfc@edk2.groups.io&g= t;
Cc: Ard Biesheuvel <= ardb+tianocore@kernel.org>, Leif Lindholm <quic_llindhol@quicinc.com>, Pierre Gondois &l= t;Pierre.Gondois@arm.com>, Sami Mujawar <Sami.Mujawar@arm.= com>
Subject: DynamicTablesPkg: Keeping AcpiProcessorId in PPTT and _UID = in SSDT in sync?

=  

Currently the SSDT and PPTT generators in DynamicTab= lesPkg use the ProcHierarchyInfo structure to generate their ACPI tables. T= he current code for PPTT will:

  1. Set the AcpiProcessorId field in PPTT to 0 if the AcpiProcessorIdVali= d flag isn’t set, OR
  2. Throw an error if AcpiIdObj= ectToken is CM_NULL_TOKEN, OR
  3. Set the AcpiProcessorId = field in PPTT to the AcpiProcessorUid of the object pointed to by AcpiIdObj= ectToken

 

In practice (on ARM), this means that all PPTT nodes= that reference an actual processor get their ID from their GIC and all PPT= T nodes that are processor containers have their ID forced to 0. If you try= to set an ID for a processor container by setting the IdValid flag for the container it results in an error. Simi= larly, the SSDT node checker expects that all nodes that have the IdValid f= lag set also have their Leaf flag set and are leaf nodes; it will throw an = error if any non-leaf node has the IdValid flag set.

 

However, the PPTT spec says (5. ACPI Software Programming Model — ACPI Specif= ication 6.5 documentation (uefi.org)):

ACPI Processor ID

4

12

If the processor structure represents an actual proc= essor, this field must match the value of ACPI processor ID field in the pr= ocessor’s entry in the MADT. If the processor structure represents a = group of associated processors, the structure might match a processor container in the name space. In that case this ent= ry will match the value of the _UID method of the associated processor cont= ainer. Where there is a mat= ch it must be represented. The flags field, described in Pro= cessor Structure Flags, includes a bit to describe whether the ACPI pro= cessor ID is valid.

and the flag

ACPI Processor ID valid

1

1

For non-leaf entries in the processor topology, the = ACPI Processor ID entry can relate to a Processor container in the namespac= e. The processor container will have a matching ID value returned through t= he _UID method. As not every processor hierarchy node structure in PPTT may have a matching processor container, = this flag indicates whether the ACPI processor ID points to valid entry. Where a valid entry = is possible the ACPI Processor ID and _UID method are mandatory. For= leaf entries in PPTT that represent processors listed in MADT, the ACPI Pr= ocessor ID must always be provided and this flag must be set to 1.

 

I read this to mean that the processor containers in= PPTT are REQUIRED to have a valid ID that matches the _UID of the correspo= nding container in SSDT.

 

To properly implement APMT support for a chip I̵= 7;m working on I need to ensure that the PPTT has a valid (non-zero) ID for= some processor containers in order to match the requirements of the APMT t= able:

ACPI for CoreSight Performance Monitoring Unit Architecture = (arm.com)

Processor affinity

4

48

Processor affinity for this PMU. This field must mat= ch the ACPI Processor ID of the PPTT Type 0 structure that represents the p= rocessor or processor container that this PMU is associated with.

 

As a result, I’m working on a patch to enable = the SSDT and PPTT generators to generate a valid ID for processor container= nodes, but I need some guidance. It isn’t too hard to update the exi= sting code to:

  1. Allow non-leaf nodes to have the ID valid flag set
    2. Generate the ID if the ID valid flag is set AND the ProcHierarchyInfo st= ructure specifies it explicitly via the OverrideNameUidEnabled flag and its= corresponding OverrideUid field.

 

However, I’m not sure how to handle the case w= here ProcHierarchyInfo says a valid ID is needed but one is not provided vi= a Override. In this case SSDT has some logic to auto-assign _UIDs, but the = spec requires that PPTT set the AcpiProcessorId to that same value as those auto-assigned SSDT _UIDs. How should we guaran= tee that these auto-assigned values are in sync?

 

Any guidance on how to handle this?

 

Thanks,

 

Jeshua Smith

NVIDIA

_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#120360) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--_000_SJ0PR12MB69894999102C10896467677DDB812SJ0PR12MB6989namp_--