Re: [PATCH RFC] x86/cacheinfo: Remove get_cache_id() due to ID collisions

[Javid Rzayev]

On Thu, Mar 19, 2026 at 05:38:00AM -0700, Ricardo Neri wrote:
> calc_cache_topo_id() and get_cache_id() both compute cache IDs used to
> determine which CPUs share a cache. Intel processors use
> calc_cache_topo_id(), while Hygon and recent AMD processors use
> get_cache_id(). Intel processors use get_cache_id() as well, but only to
> populate /sys/devices/system/cpu/cpuN/cache/index*/id.

Hi Ricardo,

On Intel hybrid parts the bad IDs do not stay confined to
cache/index*/id: after CPU hotplug they leak into shared_cpu_list.

I hit the collision on Arrow Lake-S (Core Ultra 7 265, 8P+12E, no
SMT). Even without SMT, CPUID leaf 4 on the P-cores reports 2 threads
sharing L1, so get_cache_id() shifts P-core APIC IDs by 1 and E-core
APIC IDs by 0:

  CPU  type  APICID  L1 id (unpatched)
   4   P     0x30    0x18
   8   E     0x18    0x18   <- collides with CPU4
   5   P     0x38    0x1c
  10   E     0x1c    0x1c   <- collides with CPU5

When a CPU goes offline, cache_shared_cpu_map_remove() clears
cpu_map_populated. When it comes back online, the LLC is still valid,
so x86 populate_cache_leaves() is skipped and the generic
cache_shared_cpu_map_setup() rebuilds the maps by comparing ci->id.

On v7.4-rc2 (unpatched), right after boot L1 shared_cpu_list is
correct (cpu4: "4", cpu8: "8") and only the IDs collide. After
offlining and onlining cpu8 it becomes "4,8" for both CPUs, i.e. a
P-core and an E-core appear to share L1. On a distro 6.12 kernel,
after several suspend/resume cycles both pairs (4,8 and 5,10) were
wrong.

With this patch applied on v7.4-rc2, L1 IDs equal the APIC IDs and
are unique. Offlining/onlining cpu8 and cpu10 leaves all
shared_cpu_lists intact. L2 IDs change (e.g. 0x3 -> 0x18 for the
cluster of CPUs 8-11) but the shared_cpu_lists are unchanged.

It may be worth mentioning the hotplug effect in the changelog. Do you
plan to post a non-RFC version to the x86 maintainers?

Tested-by: Javid Rzayev <rz.cavid@xxxxxxxxx>

Thanks,
Javid