Re: [PATCH v9 05/12] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online

[Reinette Chatre <reinette.chatre@intel.com>]

On 10/23/26 4:57 PM, Reinette Chatre wrote:
> Hi Chenyu,
> 
> On 10/13/26 7:58 PM, Chen Yu wrote:
>> In preparation for MMIO-based LLC occupancy monitoring, link the per-domain
>> ERDT information to the resctrl L3 monitoring domain, so the MMIO read path
>> can locate a domain's MMIO registers.
> 
> Please review "Changelog" section of Documentation/process/maintainer-tip.rst
> I understand other subsystems need a snippet that describes the change at the
> top of changelog but x86 does not. Unless it is something really simple, which
> this is not, there has to be some context before the change is described.
> 
>>
>> ERDT and CPUID enumerate CPU-to-L3-domain membership independently: CPUID leaf 4
>> describes the L3 cache topology, while the firmware CACD sub-table lists the
>> CPUs of each ERDT domain. Both views must agree on a CPU's L3 domain for that
>> CPU to be monitored safely.
>>
>> When a CPU comes online, validate that firmware and CPUID agree on its L3 domain
>> and bind the CPU to its ERDT domain before adding it to any resctrl domain.
> 
> "bind the CPU to its ERDT domain" is this not what patch #3 did?
> 
> "adding it" - what does "it" refer to? the ERDT domain or the CPU?
> 
>> Fail the CPU online operation on a mismatch for now. Leaving the CPU
>> online but outside all resctrl domains is doable, but it would require a
>> change to cpus_ctrl_write() to reject CPUs that are online but not tracked by
>> any resctrl group. The current approach is stricter, but simpler.
> 
> I do not believe failing the CPU online operation is actually possible.
> 
> resctrl_arch_late_init() is a late initcall and all boot CPUs are already online,
> so the failure during this time will result in resctrl not being initialized at
> all without impacting online CPUs. A CPU onlined after that will fail to
> initialize, but that will make the CPU unusable for *everything*, not just 
> unmonitored. This sounds extreme for an ERDT table issue that should never happen.
> 
> A CPU that is online is still able to run tasks and the earlier enumeration 
> ensured that MSR_IA32_PQR_ASSOC is accessible and what the valid values for it
> are. Even this "failure" path demonstrates this by calling clear_closid_rmid()
> that writes to MSR_IA32_PQR_ASSOC *after* the supposed failure.
> 
> resctrl's current behavior when a CPU cannot be onlined, for example when
> domain creation fails, is to *not* prevent CPU from onlining. If a domain
> cannot be created then the CPU is still added to the default group's
> CPU mask (resctrl_online_cpu()) to ensure that tasks can continue to
> be scheduled on it by writing to MSR_IA32_PQR_ASSOC with values known to
> be valid.
> 
> Such a CPU is *not* added to a domain's CPU mask so resctrl will not
> attempt to make any configuration changes to it or read any counters from it.
> 
correction: with the CMT event marked as "any_cpu" it may be possible for
the counter to be read from a CPU that was not added to the domain, but this
read will go to MMIO that should succeed? At this point the system will already
be in a state with the logs showing "Firmware Bug" so further attempts at using
resctrl cannot be expected to be ideal. The CPU should continue to be usable
otherwise.

Reinette