On Wed, Oct 28, 2020 at 03:14:43PM +0000, Catalin Marinas wrote: > On Wed, Oct 28, 2020 at 12:27:59PM +0000, Will Deacon wrote: > > On Wed, Oct 28, 2020 at 12:15:07PM +0000, Catalin Marinas wrote: > > > On Tue, Oct 27, 2020 at 09:51:17PM +0000, Will Deacon wrote: > > > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu > > > > index b555df825447..19893fb8e870 100644 > > > > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > > > > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > > > > @@ -472,6 +472,14 @@ Description: AArch64 CPU registers > > > > 'identification' directory exposes the CPU ID registers for > > > > identifying model and revision of the CPU. > > > > > > > > +What: /sys/devices/system/cpu/aarch32_el0 > > > > > > Nitpick: should we call this aarch32_el0_present? It's not exactly > > > present as we populate it as CPUs come online but it's closer to this > > > mask than to the online one. > > > > I don't think so, because a CPU could be set in this mask but not in the > > present mask, which is hugely confusing it it has "present" in the name! > > How can it end up here but not in the present mask? We populate present > early if they have a corresponding DT entry. I was under the impression that physical CPU hotplug with ACPI would clear the entry in the present mask, but I can't say I have any machines that I can test that with and it looks like it might only be implemented for x86 at the moment. That said, it looks like cpu_die_early() also marks CPUs as not being present and this can happen due to a late capability conflict. Will
