Now, it is unsuitable for both ARMv8 and ARMv9 to show a
fixed string "CPU architecture: 8" in /proc/cpuinfo.
Signed-off-by: Rongwei Wang <[email protected]>
---
arch/arm64/kernel/cpuinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 330b92e..6d9b7e8 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -195,7 +195,7 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "CPU implementer\t: 0x%02x\n",
MIDR_IMPLEMENTOR(midr));
- seq_printf(m, "CPU architecture: 8\n");
+ seq_printf(m, "CPU architecture: aarch64\n");
seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
--
1.8.3.1
On Mon, Mar 07, 2022 at 11:04:17AM +0800, Rongwei Wang wrote:
> Now, it is unsuitable for both ARMv8 and ARMv9 to show a
> fixed string "CPU architecture: 8" in /proc/cpuinfo.
>
> Signed-off-by: Rongwei Wang <[email protected]>
> ---
> arch/arm64/kernel/cpuinfo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 330b92e..6d9b7e8 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -195,7 +195,7 @@ static int c_show(struct seq_file *m, void *v)
>
> seq_printf(m, "CPU implementer\t: 0x%02x\n",
> MIDR_IMPLEMENTOR(midr));
> - seq_printf(m, "CPU architecture: 8\n");
> + seq_printf(m, "CPU architecture: aarch64\n");
In hindsight, 'aarch64' would have made more sense since 8/9/10 whatever
are just marketing. That said, we should not apply this patch as it has
potential ABI implications.
--
Catalin
On Mon, 07 Mar 2022 12:13:50 +0000,
Rongwei Wang <[email protected]> wrote:
>
>
>
> On 3/7/22 4:45 PM, Marc Zyngier wrote:
> > On Mon, 07 Mar 2022 03:04:17 +0000,
> > Rongwei Wang <[email protected]> wrote:
> >>
> >> Now, it is unsuitable for both ARMv8 and ARMv9 to show a
> >> fixed string "CPU architecture: 8" in /proc/cpuinfo.
> >
> > Please read the various threads that have been going on over the past
> > 10+ years about *why* we don't allow this sort of change (TL;DR: it
> > breaks userspace, and we don't do that).
> >
> > Also, there is no material difference between v8 and v9 that would be
> > observable from userspace outside of the "Features:" line. And if that
> > doesn't convince you, just think of '8' as the number of bytes
> > used by
> I got your point. It seems that we can regard '8' as the number of
> bytes. But what make me do this is that 'CPU architecture: 8' is
> confusing, especially those responsible for testing.
> And I believe that most people regard this '8' as ARMv8, maybe not.
That was the original intention. But given that there is no userspace
visible difference between v8, v9 and whatever comes after it, this
is a pointless change. My comment about the size of a VA was just a
joke, and not something to be taken seriously.
> In fact, I'm not sure it has potential ABI implications, so seek your
> advice.
Plenty of userspace programs parse /proc/cpuinfo. If you replace '8'
with anything else, they will fail. Which is why although your patch
makes sense, it comes 10 years too late, and we can't change this
anymore.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On 07/03/2022 12:23 pm, Marc Zyngier wrote:
> On Mon, 07 Mar 2022 12:13:50 +0000,
> Rongwei Wang <[email protected]> wrote:
>>
>>
>>
>> On 3/7/22 4:45 PM, Marc Zyngier wrote:
>>> On Mon, 07 Mar 2022 03:04:17 +0000,
>>> Rongwei Wang <[email protected]> wrote:
>>>>
>>>> Now, it is unsuitable for both ARMv8 and ARMv9 to show a
>>>> fixed string "CPU architecture: 8" in /proc/cpuinfo.
>>>
>>> Please read the various threads that have been going on over the past
>>> 10+ years about *why* we don't allow this sort of change (TL;DR: it
>>> breaks userspace, and we don't do that).
>>>
>>> Also, there is no material difference between v8 and v9 that would be
>>> observable from userspace outside of the "Features:" line. And if that
>>> doesn't convince you, just think of '8' as the number of bytes
>>> used by
>
>> I got your point. It seems that we can regard '8' as the number of
>> bytes. But what make me do this is that 'CPU architecture: 8' is
>> confusing, especially those responsible for testing.
>> And I believe that most people regard this '8' as ARMv8, maybe not.
>
> That was the original intention. But given that there is no userspace
> visible difference between v8, v9 and whatever comes after it, this
> is a pointless change. My comment about the size of a VA was just a
> joke, and not something to be taken seriously.
>
>> In fact, I'm not sure it has potential ABI implications, so seek your
>> advice.
>
> Plenty of userspace programs parse /proc/cpuinfo. If you replace '8'
> with anything else, they will fail. Which is why although your patch
> makes sense, it comes 10 years too late, and we can't change this
> anymore.
And arguably it's not even too late, because 10 years ago this *did* say
"AArch64". I don't remember all the exact details behind commit
44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
of a memory to go and look up the git history - but I don't think we
changed any of those fields without a real reason.
Robin.
On 2022-03-07 19:30, Arnd Bergmann wrote:
> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
>
>> And arguably it's not even too late, because 10 years ago this *did* say
>> "AArch64". I don't remember all the exact details behind commit
>> 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
>> of a memory to go and look up the git history - but I don't think we
>> changed any of those fields without a real reason.
>>
>
> The patch description does state that this was done for compatibility with
> 32-bit architectures, which does make some sense. I suppose for similar
> reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
> 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
>
> The part that I find more annoying is how we leave out the one bit
> of information that people are generally looking for in /proc/cpuinfo:
> the name of the processor. Even though we already know the
> exact processor type in order to handle the CPU errata, this is
> always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
> and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
> with the revision being the least important bit of information here...
Eh, it's hardly impossible to recompose a MIDR value from the
implementer, part, variant and revision fields if one actually needs to.
Maybe we could null-terminate the raw MIDR value and print it as a
string of largely-unprintable characters in the "model name" field... I
guess that might satisfy the crowd who want parity* with x86 CPUID, at
least :)
Robin.
* Of course this is a complete lie, because every time that comes up
it's always really about the microarchitecture (which Arm's CPU core
marketing names represent), where x86 is perfectly on par with arm64
with its equivalently-inscrutable "cpu family" and "model" numbers,
rather than cool microarchitecture names like "Sausage Lake" or whatever...
On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote:
> On 2022-03-07 19:30, Arnd Bergmann wrote:
> > On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
> >
> > > And arguably it's not even too late, because 10 years ago this *did* say
> > > "AArch64". I don't remember all the exact details behind commit
> > > 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
> > > of a memory to go and look up the git history - but I don't think we
> > > changed any of those fields without a real reason.
> > >
> >
> > The patch description does state that this was done for compatibility with
> > 32-bit architectures, which does make some sense. I suppose for similar
> > reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
> > 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
> >
> > The part that I find more annoying is how we leave out the one bit
> > of information that people are generally looking for in /proc/cpuinfo:
> > the name of the processor. Even though we already know the
> > exact processor type in order to handle the CPU errata, this is
> > always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
> > and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
> > with the revision being the least important bit of information here...
>
> Eh, it's hardly impossible to recompose a MIDR value from the implementer,
> part, variant and revision fields if one actually needs to. Maybe we could
> null-terminate the raw MIDR value and print it as a string of
> largely-unprintable characters in the "model name" field... I guess that
> might satisfy the crowd who want parity* with x86 CPUID, at least :)
Actually, it is impossible to do it reliably. I won't expand on this,
except what I said in my other reply - there are cases where the MIDR
value is not unique.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
> And arguably it's not even too late, because 10 years ago this *did* say
> "AArch64". I don't remember all the exact details behind commit
> 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
> of a memory to go and look up the git history - but I don't think we
> changed any of those fields without a real reason.
>
The patch description does state that this was done for compatibility with
32-bit architectures, which does make some sense. I suppose for similar
reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
The part that I find more annoying is how we leave out the one bit
of information that people are generally looking for in /proc/cpuinfo:
the name of the processor. Even though we already know the
exact processor type in order to handle the CPU errata, this is
always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
with the revision being the least important bit of information here...
Arnd
On 2022-03-08 17:18, Catalin Marinas wrote:
> On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote:
>> On 2022-03-07 19:30, Arnd Bergmann wrote:
>>> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
>>>
>>>> And arguably it's not even too late, because 10 years ago this *did* say
>>>> "AArch64". I don't remember all the exact details behind commit
>>>> 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
>>>> of a memory to go and look up the git history - but I don't think we
>>>> changed any of those fields without a real reason.
>>>>
>>>
>>> The patch description does state that this was done for compatibility with
>>> 32-bit architectures, which does make some sense. I suppose for similar
>>> reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
>>> 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
>>>
>>> The part that I find more annoying is how we leave out the one bit
>>> of information that people are generally looking for in /proc/cpuinfo:
>>> the name of the processor. Even though we already know the
>>> exact processor type in order to handle the CPU errata, this is
>>> always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
>>> and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
>>> with the revision being the least important bit of information here...
>>
>> Eh, it's hardly impossible to recompose a MIDR value from the implementer,
>> part, variant and revision fields if one actually needs to. Maybe we could
>> null-terminate the raw MIDR value and print it as a string of
>> largely-unprintable characters in the "model name" field... I guess that
>> might satisfy the crowd who want parity* with x86 CPUID, at least :)
>
> You can get the MIDR from
> /sys/devices/system/cpu/cpu*/regs/identification/midr_el1.
>
> As for printing the actual names, we thought we'd leave it to tools like
> lscpu. I'm not keen on maintaining a dictionary of MIDR to CPU marketing
> names in the kernel, deal with rebranding and so on. For x86 you can get
> the name from the CPU itself IIUC, that's not the case for arm.
Yes, CPUID reads a string out of the hardware which is the name for the
*physical product*, which among other things is allegedly useful to
dissuade unscrupulous people from grinding the markings off and
re-etching them to fake a higher-spec chip. We obviously can't maintain
a whole database of SoC names in Linux.
In fact on my x86 box, even lscpu still doesn't tell me what the actual
CPU cores are other than family 6 model 79, so in that respect Arm
support is already ahead! :D
Robin.
On Mon, Mar 07, 2022 at 08:30:07PM +0100, Arnd Bergmann wrote:
> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
>
> > And arguably it's not even too late, because 10 years ago this *did* say
> > "AArch64". I don't remember all the exact details behind commit
> > 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
> > of a memory to go and look up the git history - but I don't think we
> > changed any of those fields without a real reason.
> >
>
> The patch description does state that this was done for compatibility with
> 32-bit architectures, which does make some sense. I suppose for similar
> reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
> 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
>
> The part that I find more annoying is how we leave out the one bit
> of information that people are generally looking for in /proc/cpuinfo:
> the name of the processor. Even though we already know the
> exact processor type in order to handle the CPU errata, this is
> always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
> and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
> with the revision being the least important bit of information here...
It would have been nice if one could read the processor name out of
the processor itself... but alas that doesn't exist. Then we
wouldn't need some way to translate MIDR values to the processor.
Sadly, though, some MIDR values are not unique...
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote:
> On 2022-03-07 19:30, Arnd Bergmann wrote:
> > On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
> >
> > > And arguably it's not even too late, because 10 years ago this *did* say
> > > "AArch64". I don't remember all the exact details behind commit
> > > 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
> > > of a memory to go and look up the git history - but I don't think we
> > > changed any of those fields without a real reason.
> > >
> >
> > The patch description does state that this was done for compatibility with
> > 32-bit architectures, which does make some sense. I suppose for similar
> > reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
> > 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
> >
> > The part that I find more annoying is how we leave out the one bit
> > of information that people are generally looking for in /proc/cpuinfo:
> > the name of the processor. Even though we already know the
> > exact processor type in order to handle the CPU errata, this is
> > always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
> > and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
> > with the revision being the least important bit of information here...
>
> Eh, it's hardly impossible to recompose a MIDR value from the implementer,
> part, variant and revision fields if one actually needs to. Maybe we could
> null-terminate the raw MIDR value and print it as a string of
> largely-unprintable characters in the "model name" field... I guess that
> might satisfy the crowd who want parity* with x86 CPUID, at least :)
You can get the MIDR from
/sys/devices/system/cpu/cpu*/regs/identification/midr_el1.
As for printing the actual names, we thought we'd leave it to tools like
lscpu. I'm not keen on maintaining a dictionary of MIDR to CPU marketing
names in the kernel, deal with rebranding and so on. For x86 you can get
the name from the CPU itself IIUC, that's not the case for arm.
--
Catalin
On 2022-03-08 17:57, Russell King (Oracle) wrote:
> On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote:
>> On 2022-03-07 19:30, Arnd Bergmann wrote:
>>> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <[email protected]> wrote:
>>>
>>>> And arguably it's not even too late, because 10 years ago this *did* say
>>>> "AArch64". I don't remember all the exact details behind commit
>>>> 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
>>>> of a memory to go and look up the git history - but I don't think we
>>>> changed any of those fields without a real reason.
>>>>
>>>
>>> The patch description does state that this was done for compatibility with
>>> 32-bit architectures, which does make some sense. I suppose for similar
>>> reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
>>> 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
>>>
>>> The part that I find more annoying is how we leave out the one bit
>>> of information that people are generally looking for in /proc/cpuinfo:
>>> the name of the processor. Even though we already know the
>>> exact processor type in order to handle the CPU errata, this is
>>> always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
>>> and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
>>> with the revision being the least important bit of information here...
>>
>> Eh, it's hardly impossible to recompose a MIDR value from the implementer,
>> part, variant and revision fields if one actually needs to. Maybe we could
>> null-terminate the raw MIDR value and print it as a string of
>> largely-unprintable characters in the "model name" field... I guess that
>> might satisfy the crowd who want parity* with x86 CPUID, at least :)
>
> Actually, it is impossible to do it reliably. I won't expand on this,
> except what I said in my other reply - there are cases where the MIDR
> value is not unique.
Sorry, I was assuming the given context of CPUs which report as v7 or
v8, where one can safely and unambiguously infer that the missing
original MIDR.Architecture value was 0xf. No implication was intended
that it was possible for everything in general.
Robin.