Received-SPF: pass (google.com: domain of linux-kernel+bounces-173373-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <c25073f0-5af2-42ca-bf61-e85df2711e3c@marvell.com>
Date: Wed, 8 May 2024 19:25:33 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1 13/14] arm_mpam: Handle resource instances mapped to
 different controls
To: Peter Newman <peternewman@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org"
 <linux-arm-kernel@lists.infradead.org>,
        "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
        "reinette.chatre@intel.com" <reinette.chatre@intel.com>,
        "james.morse@arm.com" <james.morse@arm.com>,
        George Cherian <gcherian@marvell.com>,
        "robh@kernel.org" <robh@kernel.org>,
        "dfustini@baylibre.com" <dfustini@baylibre.com>,
        "jonathan.cameron@huawei.com" <jonathan.cameron@huawei.com>,
        Tony Luck <tony.luck@intel.com>, Dave Martin <Dave.Martin@arm.com>
References: <20240117141405.3063506-1-amitsinght@marvell.com>
 <20240117141405.3063506-14-amitsinght@marvell.com>
 <CALPaoCjf_A5SOr8L+0WMePW02Pzj9nnPT0JLZ_+232vvfEzGCQ@mail.gmail.com>
 <MW4PR18MB508449310648615886A8113BC6702@MW4PR18MB5084.namprd18.prod.outlook.com>
 <CALPaoCi1xABN+7LL4Xyi4Se87f8PM8769KiyZkzTESurZSyDqg@mail.gmail.com>
Content-Language: en-US
From: Amit Singh Tomar <amitsinght@marvell.com>
In-Reply-To: <CALPaoCi1xABN+7LL4Xyi4Se87f8PM8769KiyZkzTESurZSyDqg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?V3NFRnoza2p3aW9WS2tvZHhvYXRaeFZuNFpmd0owMjg0NkxKcjR3VU0xQWxH?=
 =?utf-8?B?NHBIdFhCbzdzbTlWVHUrdlRnTXdTenN3bTZPY0Mra1I5Nk1vczI4TmNhMDRU?=
 =?utf-8?B?aHFwWENTWjN4ZWFEb2pjZGRYMTJyWkltVkJYcUkwUDZ3R3lxY045dHJXdGdS?=
 =?utf-8?B?K1VjRXV1NWYwNU9Da3dWNXgyV0ZHZlY2Tk5yOW14dmpGeDJpd1Z4OW4rQmtR?=
 =?utf-8?B?QkRkbTZxMEtFcWhlYklKUVRxSERvcTY0aGZ6TEJ6Z0c5NjdmVTV6TkppZnUv?=
 =?utf-8?B?S1JOTnhPc0I4cStGUFlpMmxlQlIrbE5CTkczSHhkK3RPSENTaHU2K3N5YWFM?=
 =?utf-8?B?MTZXa2QxWHQ0SUJCYlJHdlhWeGFKT0g1a2xtY2xzU3hlcEdoT01YU0pMU2VY?=
 =?utf-8?B?Vk12RFBtN0phQzRGTktuYzArR0w3ZFJhUlFMR0kwYjE1akh3RENEV1BLbGRz?=
 =?utf-8?B?ejRSVTI5NE1LYlM5dElnMmpVSWMxN2pIclJpOFlFZlVKZnFSUXFhZTVhdmpw?=
 =?utf-8?B?akNyRlBxNGdZQnZJNFB5ZFFCYTdrSmN1VnlRQWVNOGRxZjRKTUd4QzQzNUZ1?=
 =?utf-8?B?R0srUHBpNWI4VmdHWGFWanY0ZG9SYWc3L1dhK1REa0d4RGlBbVE1ZmdOYVhr?=
 =?utf-8?B?d0ZtQXZHR05rQU95WFoxZjRUSmNjb1QzSzE2R0FuSnk1M2Y5RU56bUdnaWZM?=
 =?utf-8?B?K3FPK1M1SkZuUm1McHp4S1lxYjd0L0dVYkVjdnpHUGg5UHprODhEbHowOFFq?=
 =?utf-8?B?MlRrelFhaFJpLzNqKzhoTkhiOXlzQnJRdkNrajFhUXZ1dVhpdVZuM0Z3RnR4?=
 =?utf-8?B?Y2VobGh6WXhnb0E2NTcxa2phQWkwZC83d0hmSktacm1ZUU9ENzJzS2pPa20v?=
 =?utf-8?B?cHJFYVBYa0VXOGorYXp2UEFUN2tGOW9IU2o2Z0tGRzNUZy9ja2h5b3U4NUJ0?=
 =?utf-8?B?OVR6TUJvLyt4ZXl0QWZLSk9yYUt1cU1QSW5BT21pQkdweUN5bWwxTGNEb1hq?=
 =?utf-8?B?cUVuTFRpVlNTSXdJeWlhRVl4alJvZU1teE9TZytQbGQ4cElQMWhYeUQ4VG01?=
 =?utf-8?B?eXpCVk1jb2xraXJTR2tVbG5zbUtETzc4V3NweG9aNHp3cmxTb1JmTWJ3YkhG?=
 =?utf-8?B?VGhyM3E2U1NIZ2xZckVHanJ3S3Z3THVGTTE5LzhKZTBvSG9TRm9Kd1psMlVI?=
 =?utf-8?B?YktPd3FCNVk5ZXRKdlZLd0YyWXVYZC9FNEp5K3FubkVEYkNkYzZrbkZGbGZ1?=
 =?utf-8?B?M0Fad3ZNY1FXSHZJcHBUbkRvVnRHUEJrb0QrQWdGaThnR1JWQ1lWRzV6dFA5?=
 =?utf-8?B?SGZpbDZZQW9XSWxMNTZTaVI3STQyZDJMeEhuQWxGdzN2ZWtIdFFZNDlkL2dT?=
 =?utf-8?B?Y0M3eEZKRTNsaENHa0hoZ1grNDR3d2JLbUJkYUxSNWRGemdHSTg5dThaOXIx?=
 =?utf-8?B?Yy93RFJOSHdUQ08vcHNyWDZRRHVwYlFqME45eC8xWjFUbjNoUnNiRkN2OXRs?=
 =?utf-8?B?VWgvWXpINkJqaEVZUGtrcnVEcEovbEhzT0dXQUxpTFE3Y2E4c0tBUEVnK1dq?=
 =?utf-8?B?VWJTdXV2L1djOVhpTzNYWERwd050MEMvckpxMVVkOCtmWjIyeVgyZG4vOGMy?=
 =?utf-8?B?M243bWZtOU11eHFjOFZXOW9HR3dwM3F1L1ZTN0ZJWXJYc0FPYUF1WnpUdmNx?=
 =?utf-8?B?RERQRy9iUGRWSzZ3NlZScXlOOTg4T0F3VDdYNVRHUDZoNjdpWUZaeWQ5MzZK?=
 =?utf-8?B?by94RkduYlpIQ2hrVmhtMXpHNHlaUDI2eGNLSHo0bmV0MFF1NFJyM2s1LzBo?=
 =?utf-8?B?UUxGUURvQmw2Q25rVWNwZnQ0ODZWODNsbUdhVm5SUzMzU3FjOEZyU0Y2dUZZ?=
 =?utf-8?B?UkQxbDVTeCs3M1ZNR2tnUDRJcVJMT1F6T3hIL0xRUTF6c3lZOXN0TGJnd0oy?=
 =?utf-8?B?T2RCTzQ0eGxqSHQ5cXRwV0Y0b1A1UmJMenhZWW5aU0w0TWdoVlh1dkp4OC9j?=
 =?utf-8?B?Vy9QcGlXNUxrYWRsVzFBaXRsN0VQUnVZNndkUzc3cFU3QSs5Qm9HNHZqMDRp?=
 =?utf-8?B?eDg3NytkNGNLa1ZVelplVWh1akFKQ1BNMUZDUk1ZTlc3RlB5UzlyUlFMamtx?=
 =?utf-8?Q?rlySNXVivAPnTnB5VTC8Ztqff?=
X-OriginatorOrg: marvell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3de417cc-e647-4a8a-5c39-08dc6f668d1b
X-MS-Exchange-CrossTenant-AuthSource: MW4PR18MB5084.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2024 13:55:42.8236
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2WgcqsZ43ZQD8O79nNmMscHiXgai6eTHw4DL0zqSxO75HGzHtGCyfkVlHplYCaq1+I5c4UPb3ip5qrgXO/TfeA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR18MB5208
X-Proofpoint-GUID: XRJ849u9Xpkd_-pKGo87d9XIay1BniWn
X-Proofpoint-ORIG-GUID: XRJ849u9Xpkd_-pKGo87d9XIay1BniWn
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.11.176.26
 definitions=2024-05-08_09,2024-05-08_01,2023-05-22_02

Hi Peter,

>>
>> It looks like "club" is used as a synonym to "class" here to evade the bigger issue that mpam_classes are not defined correctly as DSPRI resources should not be in the same mpam_class as the L3 CPOR and CSU features.
>>
>> This hardware makes it clear that the definition of mpam_class as all resources in a (level x {memory,cache}) needs to be revised.
>>
>> On Marvell platform, DSPRI control register (MPAMCFG_PRI_NS), and Identification Register (MPAMF_PRI_IDR_NS)  are implemented within the LLC MPAM block (the address range contains control and identification registers for CPOR, and DSPRI), and therefore we treat DSPRI as one of the L3 resource. However, suppose we approach it as totally different standalone resource type (PRI) other than Cache storage resource type (CPOR, and CCAP), and define a new MPAM class type for it, there is no standard way to discover this new resource type (PRI) from ACPI tables.
>>
>> I'm concerned about accessing DSPRI related registers, if we are going to tide it to new MPAM class (as we discover whole L3 MPAM block using firmware tables, and tide it's resources to L3 MPAM class).
> 
> This is becoming more of a discussion of MPAM (and resctrl) in
> general, so I hope James can participate. Also I should point out that
> when discussing MPAM, "resource" refers to a non-RIS MSC or a single
> RIS-index on a RIS-enabled MSC, while the "mpam_class" structure in
> the code is the counterpart to what RDT (and resctrl) call a resource.
> 
>  From my reading of the code, the consequence of (RIS) resources being
> in the same mpam_class is that they can be programmed uniformly
> through a single schema line in the schemata file, so
> __resource_props_mismatch() goes to work on eliminating any resources
> (and extra control granularity) which are not programmed exactly the
> same way. This function seems more geared toward big.LITTLE systems
> where the cache controls on one cluster are dissimilar from those on
> the peer cluster and would need to be normalized (James, can you
> confirm?). But in this situation, it seems like a better idea to
> present a separate schema for one cluster's controls from the others.
> For example, "L2P" and "L2E", with non-overlapping domains.
> 
> In the case of an MSC implementing RIS, the controls are independent
> by definition, 
This greatly relies on the implementation.

For an MSC, identical control may be situated at two separate indexes, 
each with different attributes. For instance, let's take an example
of MARVELL implementation, There are three different resources at index 
0,1,2. These are enumerated in TAD_CMN_MPAM_RIS_E:

0: MSC
1: LTG
2: DTG

LLC MSC, resource at index 1, and 2 possesses cache portion partitioning 
feature, i.e., If MPAMCFG_PART_SEL_NS[RIS] is set to 1 (LTG) or to 2 
(DTG), then MPAMF_IDR_NS[HAS_CPOR_PART] is set to 1. LTG resource has 16 
portion bitmap, and DTG has 18 portion bitmap (mapped to same CPOR 
control), and only one can be configured.

so I can't see why the work done in
> __resource_props_mismatch() would be applicable.
>
IMHO, __resource_props_mismatch would be needed for such cases.

Thanks
-Amit