From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B2E863F23CF for ; Thu, 2 Jul 2026 14:27:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783002449; cv=none; b=dYKSao85em40qU9gBCy5l/+dOHHHEtOtbta8Uwcw+1P+r3OfikhznFlLgksZ89thE6JBgpZzuN94nV7PJs1rvIxMCdS5zsu/LOr8J7Qh15XaNtVFIliqalr6R28gNkiUMMCondc7y7iTYcTjqM8JLcWTS8kYM2QXC2udTi23zMQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783002449; c=relaxed/simple; bh=UyvdZIU0+/2dmRJNCVQGpqT+4UeoAC1SXLBBQ9OpqFw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BTpfHifS4UWOZ0oNUiv0CbwnM42WMmIFs4HsD0EwJQ1iBe0Y+z846RZCBOWteTSIIVwf2C2WWrBqAdn0NFLriTisG++KNW2aB2fz5f4E8rH6dHBMYIT/XeDdDPD22gwMP4lUa1ACSvNCZiVVtXyywCwrv1ssu4AB0Y8p/n50bV4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=PRmMVyPK; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="PRmMVyPK" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D690359D; Thu, 2 Jul 2026 07:27:22 -0700 (PDT) Received: from [10.2.212.8] (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 76FBC3F673; Thu, 2 Jul 2026 07:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783002446; bh=UyvdZIU0+/2dmRJNCVQGpqT+4UeoAC1SXLBBQ9OpqFw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=PRmMVyPKi5Z4HWJKm7yOJM6yQVVboMOKV1i2mtT/ooTyDpsqA3vH0snaWZ/P4x0gG 3uSoMuIgDVGVN+jdfMvA3PWD8z+z+tKuHlfuw41ie5w25GcEyb2UUx96QlD7Nlo64Q CsukomzhuyR75vNAMOcgQwi0Ot5C7KDnxATKNHPc= Message-ID: <208b36c8-985a-4ff2-8ecd-b9376bb4eba4@arm.com> Date: Thu, 2 Jul 2026 15:27:22 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: "Chen, Yu C" , Reinette Chatre Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Tony Luck , Dave Martin , James Morse , Drew Fustini , Babu Moger , Fenghua Yu , chen.yu@linux.dev References: <29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com> <7f2d0cc3-266c-4fa3-a9ba-7352325c76d1@intel.com> <3ef279c9-c4b3-48cb-8235-da8a871b54f9@arm.com> <5cffdb88-924e-43e7-84f2-ea19d82910fb@intel.com> <0c957e0a-0188-40c0-96e6-4e5d787a8ae6@arm.com> <8bd94a5f-1460-4bc3-a2b2-68a298200ad8@intel.com> <36213825-c353-46b4-8a05-83ea446201a4@intel.com> <2a06bfde-2740-4bde-8ffb-aa2026d6edd1@intel.com> <6f7a02ec-03fc-4c9c-af86-239f98b9b903@intel.com> Content-Language: en-US From: Ben Horgan In-Reply-To: <6f7a02ec-03fc-4c9c-af86-239f98b9b903@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Chenyu, On 6/26/26 16:46, Chen, Yu C wrote: > Hi Reinette, > > On 6/11/2026 11:45 PM, Reinette Chatre wrote: >> Hi Chenyu, >> >> On 6/10/26 8:26 PM, Chen, Yu C wrote: >>> On 6/10/2026 11:59 PM, Reinette Chatre wrote: >>> [ ... ] >>> >>>> >>>> -  This implies that all current and future ERDT capable systems >>>> will keep >>>>      supporting MSR access with the legacy "percentage based >>>> control". Is this >>>>      accurate? What will behavior be on an ERDT system that does not >>>> support >>>>      MSR access with the percentage-based control? >>> >>> Would it make sense to encourage users to switch to MMIO-based access >>> if the >>> platform replaces MSR interfaces with MMIO-based ones? One issue with >>> emulating >>> MSR-based access is that there may not be a strict 1:1 mapping >>> between the MSR >>> range and the MMIO range. Additionally, I am unsure whether both are >>> strictly >>> linearly scalable, so it could be challenging to create a proper >>> mapping for >>> msr_value_emulated = map(mmio_value) IIUC. >> >> resctrl needs to continue to offer the MB percentage based control to >> not break any >> existing tools that may take a while to transition to the new control >> interface. >> >> I believe all architectures will encourage their users to use the >> finer grained >> controls while I also expect users and their tools would gradually >> switch by themselves >> to benefit from the improved capabilities. >> > > The following are current thoughts on how Control B can emulate Control A. > May I know if this direction is acceptable? > > The main idea is that, Legacy MBA controller delegates to region-aware MBA > controller via a pointer, with its hw_update function converting > percentages > to the target's value range. > > struct resctrl_hw_ctrl { >     struct resctrl_ctrl  r_ctrl; >     unsigned int         msr_base; >     void                 (*hw_update)(struct hw_param *m); >     /* points to the backing controller */ >     struct resctrl_ctrl  *r_ctrl_emul;  <-- newly added > }; What's the reason for this being in the architecture specific code? I would expect that the resctrl core code would need to know about any emulation even if the exact emulation is architecture specific? Thanks, Ben > > On boot, region-aware controllers shall be created first, followed by the > legacy MBA controller. When ERDT is enabled for legacy MBA, hw_update is > assigned to mba_emul_update() instead of mba_wrmsr_intel(). Meanwhile, > r_ctrl_emul points to the MAX controller of region0. > > In mba_emul_update(), the legacy MSR value is scaled to the range of > region0 > MAX controller by referencing r_ctrl_emul->membw.max_bw and r_ctr_emul- >>membw.min_bw. > This maps the original input range [1, 100] to a new range [1, L], where > L <= 255. > > This emulation logic can also be extended to other controllers. > > thanks, > Chenyu > > >