While we may not want all the other CPU informations. We likely
want to keep the CPU string as it's more practical than trying to
decode it from the family/model/stepping combination.

Amends: 35d60c59af28 ("Increase default console ring allocation size and reduce default verbosity")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
It would be preferable it such message could be written sooner, e.g right
after the family/model/stepping one of early_cpu_init() instead of at the
beginning of smp_prepare_cpus().

 xen/arch/x86/cpu/common.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index ebe2baf8b9..831da72cd8 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu)
 	const struct cpuinfo_x86 *c = cpu_data + cpu;
 	const char *vendor = NULL;
 
-	if (!opt_cpu_info)
-		return;
-
 	printk("CPU%u: ", cpu);
 
 	vendor = x86_cpuid_vendor_to_str(c->x86_vendor);
-- 
2.52.0



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On 29/01/2026 1:58 pm, Teddy Astie wrote:
> While we may not want all the other CPU informations. We likely
> want to keep the CPU string as it's more practical than trying to
> decode it from the family/model/stepping combination.
>
> Amends: 35d60c59af28 ("Increase default console ring allocation size and reduce default verbosity")
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> It would be preferable it such message could be written sooner, e.g right
> after the family/model/stepping one of early_cpu_init() instead of at the
> beginning of smp_prepare_cpus().
>
>  xen/arch/x86/cpu/common.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index ebe2baf8b9..831da72cd8 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu)
>  	const struct cpuinfo_x86 *c = cpu_data + cpu;
>  	const char *vendor = NULL;
>  
> -	if (!opt_cpu_info)
> -		return;
> -
>  	printk("CPU%u: ", cpu);
>  
>  	vendor = x86_cpuid_vendor_to_str(c->x86_vendor);

I tried deleting this function (it's almost useless), but left that out
of the NX rework because it wasn't sufficiently related.

Previously (before I was a maintainer), I did try printing this string
because it's specifically useful IMO, but others did not agree.  I'm
definitely +1 to try putting it back in.

To be useful, this wants to be in early_cpu_init() next to the place
where we unconditionally print family/model/stepping.

However, Intel at least needs to do preprocessing on the string.  (Intel
right-justifies the string, and we've got logic to undo that which we
inherited from Linux.)

While I to serialise things, this will probably be better based on top
of my NX cleanup, where you can do the Intel processing in the (now
earlier) early CPU init hook.


Also... if you fancy fixing another todo in this area.

It is only convention that these strings are ASCII, and they're
arbitrarily programmable in general.  Also things like the cmdline come
in from external sources (including people typing into a grub
interactive menu), and accidentally getting VT characters into dmesg
ruins debugging.

It would be nice to port the %pE (escaped string) format option from
Linux, so we can have some defence in depth when printing external
content.  I don't think we want anything more than the default
ESCAPE_ANY_NP behaviour.

~Andrew

On 29.01.2026 14:58, Teddy Astie wrote:
> While we may not want all the other CPU informations. We likely
> want to keep the CPU string as it's more practical than trying to
> decode it from the family/model/stepping combination.

Yet why would we want it logged several hundred times by default, on a
big enough system? IOW ...

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu)
>  	const struct cpuinfo_x86 *c = cpu_data + cpu;
>  	const char *vendor = NULL;
>  
> -	if (!opt_cpu_info)
> -		return;

... this conditional doesn't want removing, but amending. E.g.

	if (!opt_cpu_info && system_state >= SYS_STATE_smp_boot)
		return;

Jan

Le 29/01/2026 à 15:06, Jan Beulich a écrit :
> On 29.01.2026 14:58, Teddy Astie wrote:
>> While we may not want all the other CPU informations. We likely
>> want to keep the CPU string as it's more practical than trying to
>> decode it from the family/model/stepping combination.
> 
> Yet why would we want it logged several hundred times by default, on a
> big enough system? IOW ...
> 

Ah I see; one idea I had was to move this to early_cpu_init() or 
somewhere similar, and only displaying it once (only for BSP ?) ?

>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -819,9 +819,6 @@ void print_cpu_info(unsigned int cpu)
>>   	const struct cpuinfo_x86 *c = cpu_data + cpu;
>>   	const char *vendor = NULL;
>>   
>> -	if (!opt_cpu_info)
>> -		return;
> 
> ... this conditional doesn't want removing, but amending. E.g.
> 
> 	if (!opt_cpu_info && system_state >= SYS_STATE_smp_boot)
> 		return;
> 
> Jan
> 



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On 29.01.2026 17:04, Teddy Astie wrote:
> Le 29/01/2026 à 15:06, Jan Beulich a écrit :
>> On 29.01.2026 14:58, Teddy Astie wrote:
>>> While we may not want all the other CPU informations. We likely
>>> want to keep the CPU string as it's more practical than trying to
>>> decode it from the family/model/stepping combination.
>>
>> Yet why would we want it logged several hundred times by default, on a
>> big enough system? IOW ...
> 
> Ah I see; one idea I had was to move this to early_cpu_init() or 
> somewhere similar, and only displaying it once (only for BSP ?) ?

Well, we have the command line option to log data for all CPUs to help
in case of problems.

Jan