From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mx.groups.io with SMTP id smtpd.web08.21976.1661420178712172859 for ; Thu, 25 Aug 2022 02:36:19 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: huawei.com, ip: 185.176.79.56, mailfrom: hesham.almatary@huawei.com) Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MCyWV1bvxz67HKP; Thu, 25 Aug 2022 17:35:50 +0800 (CST) Received: from lhrpeml500004.china.huawei.com (7.191.163.9) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 25 Aug 2022 11:36:15 +0200 Received: from [10.202.227.118] (10.202.227.118) by lhrpeml500004.china.huawei.com (7.191.163.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 25 Aug 2022 10:36:14 +0100 Message-ID: <6df801e8-2554-2c4b-f0f6-0bf5a520196b@huawei.com> Date: Thu, 25 Aug 2022 10:36:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table To: Rohit Mathew , "devel@edk2.groups.io" , Swatisri Kantamsetti CC: Sami Mujawar , Thomas Abraham , Thanu Rangarajan , nd References: <22413.1661351959791621929@groups.io> From: hesham.almatary@huawei.com In-Reply-To: X-Originating-IP: [10.202.227.118] X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To lhrpeml500004.china.huawei.com (7.191.163.9) X-CFilter-Loop: Reflected Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hello Rohit, On 8/24/2022 5:25 PM, Rohit Mathew wrote: > 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 =E2=80=93 > > 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)=E2=80= =93 As you said, having hardcoded field names won=E2=80=99t work as the des= criptors change with locator type. > > > /// > > /// MPAM MSC Locator field > > /// > > typedef struct { > > UINT64 Descriptor1; > > UINT32 Descriptor2; > > } MPAM_LOCATOR; > > Let me know your thoughts on the approach. Thanks for the explanation. It makes sense to me, I don't have a strong bia= s=20 towards not having it as a struct. > Regards, > Rohit > > From: devel@edk2.groups.io On Behalf Of hesham.alm= atary via groups.io > Sent: 24 August 2022 15:39 > To: Andrew Fish ; devel@edk2.groups.io > Subject: Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Tabl= e > > 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 sepa= rate 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). >=20