Hi Hesham,

The idea for keeping it as separate type was to abstract locator field to have a view similar to that of its definition in the spec (MPAM ACPI 1.0, section 2.2, table 7 - Resource node.)

Something of the lines –

typedef struct {

  UINT32                   Identifier;

  UINT8                    RisIndex;

  UINT16                   Reserved1;

  UINT8                    LocatorType;

  MPAM_LOCATOR             Locator;

  UINT32                   NumDependencies;

} MPAM_MSC_RESOURCE;

Locator field could very well be a struct of UINT64 and UINT32 with just descriptor 1 and descriptor 2 as the field names  (Table 10, 2.3.2)– As you said, having hardcoded field names won’t work as the descriptors change with locator type.

///
/// MPAM MSC Locator field
///
typedef struct {
 UINT64 Descriptor1;
 UINT32 Descriptor2;
} MPAM_LOCATOR;

Let me know your thoughts on the approach.

Regards,

Rohit

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of hesham.almatary via groups.io
Sent: 24 August 2022 15:39
To: Andrew Fish <afish@apple.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table

Hello Rohit and Swatisri,

On Tue, Aug 23, 2022 at 09:11 PM, Andrew Fish wrote:

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

I'd just go for UINT64 locator1 and UINT32 locator2 and not necessarily a separate type. The interpretation of each depends on the the locator type (e.g., MPAM ACPI Tables 11-15).