Re: [PATCH v4 1/6] x86/resctrl: Parse ACPI ERDT table and map RMDD domains by L3 cache ID

["Chen, Yu C" <yu.c.chen@intel.com>]

On 6/23/2026 2:29 PM, Chen, Yu C wrote:
>>>>   From what I can tell it is tmp that is essentially returned by 
>>>> this function and it
>>>> is the result of get_cpu_cacheinfo_id() that returns the cache ID 
>>>> initialized from
>>>> CPUID leaf 0x4 ... the function name ("get_l3_cache_id_from_cacd()") 
>>>> and function comment
>>>> "Resolve L3 cache ID from CACD subtable" implies differently and the 
>>>> way this is done
>>>> makes me wonder why CACD needs to be parsed at all.
>>>>
>>>> resctrl already has a hotplug handler and it dynamically determines 
>>>> the domain ID
>>>> based on the cache ID returned from get_cpu_cacheinfo_id(). If the 
>>>> domain ID used by the
>>>> new ERDT tables can be, as it appears is done here, trusted to what 
>>>> Linux already
>>>> treating as domain ID then why is it needed to parse CACD at all? 
>>>> Why not just
>>>> pick the domain ID from RMDD directly and use it directly as domain ID?
>>>>
>>>> Later the domain ID from RMDD is just used in error messages ... 
>>>> never actually used
>>>> as a domain ID to guide the implementation so the correlation 
>>>> appears to be implicit with
>>>> this CACD parsing not intuitive.
>>>>
>>>
>>> You are right that the cache ID ultimately comes from 
>>> get_cpu_cacheinfo_id(),
>>> not from CACD directly - the function name is misleading and should 
>>> be improved.
>>>
>>> However, my understanding is that CACD parsing acts as the bridge 
>>> between ACPI's
>>> RMDD domain namespace and the kernel's L3 domain ID: CACD enumerates 
>>> which CPUs
>>> belong to each RMDD, and from those CPUs we derive the kernel-side L3 
>>> cache ID.
>>> The specification defines an RMDD DomainID as an identifier unique 
>>> within the
>>> ERDT table, yet it does not guarantee that this ID matches the 
>>> kernel’s cache ID
>>> obtained via CPUID leaf 0x4. For this reason, we omitted the RMDD 
>>> domain ID in
>>> the current release.
>>
>> get_l3_cache_id_from_cacd() implies a straightforward query and the 
>> function
>> comments supports this. At the same time the function includes what 
>> appears to be
>> sanity checks but from what you say turns out to be essential 
>> enforcement of the
>> RMDD to CPUID leaf 0x4 mapping. Is this correct? As sanity checks 
>> these additional
>> checks are ok but as RMDD to CPUID leaf 0x4 mapping enforcement I find 
>> them inadequate
>> because its correctness requires all CPUs of all domains to be online 
>> which cannot be
>> guaranteed when this initialization runs.
>>
>> Consider for example a scenario where RMDD and CPUID do not agree on 
>> which CPUs form
>> part of a domain. If only one CPU of this RMDD domain is online at the 
>> time this
>> initialization is done then the mismatch will never be noticed and 
>> resctrl will just
>> silently use the CPUID mapping, no?
>>
> 
> I suppose you are referring to the following scenario:
> CACD says CPUs {0,1,2,3} belong to RMDD-A, and CPUID says
> CPUs {0,1} share L3-X while CPUs {2,3} share L3-Y (a mismatch).
> If only CPU 0 is brought online:
> 
> get_l3_cache_id_from_cacd() iterates CACD's X2APIC list: {0,1,2,3}
> CPU 1, 2, 3 are offline -> skipped
> CPU 0 is online -> cache_id = get_cpu_cacheinfo_id(0) = L3-X,
> all passed.
> 
> Then later CPU2 is online, resctrl's hotplug creates domain L3-Y.
> But the xarray has no entry for L3-Y, so erdt_mon_read() will return
> -EIO for that domain.
> 
> If this is the case, I wonder if we could run the sanity check during
> CPU hotplug to reparse the CACD table whenever a CPU comes online. My
> thought would be to call get_l3_cache_id_from_cacd() within
> resctrl_arch_online_cpu().
> 

In fact, parsing the CACD table during CPU hotplug may not be feasible,
as the ACPI tables could have already been released. We could instead
perform the check directly against the erdt_domain_xa xarray. If a
mismatch is detected, disable ERDT and fall back to legacy MSR-based
access:

/* Called from resctrl_arch_online_cpu() */
void erdt_verify_cpu_domain(int cpu)
{
     int cache_id;

     if (!__erdt_enabled)
         return;

     cache_id = get_cpu_cacheinfo_id(cpu, RESCTRL_L3_CACHE);
     if (cache_id < 0)
         return;

     if (!xa_load(&erdt_domain_xa, cache_id)) {
         pr_warn(FW_BUG "CPU%d L3 domain %d not described by ERDT, 
disabling ERDT\n",
                cpu, cache_id);
         __erdt_enabled = false;
     }
}

thanks,
Chenyu