Re: 2.6.14: CR4 not needed to be inspected on the 486 anymore?

[Zachary Amsden]

Maciej W. Rozycki wrote:

> Hello,
>
> The following hunk of the 2.6.14 patch:
>
> diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
> index e3f362e..7a14fdf 100644
> --- a/arch/i386/kernel/process.c
> +++ b/arch/i386/kernel/process.c
> @@ -313,16 +311,12 @@ void show_regs(struct pt_regs * regs)
> 	printk(" DS: %04x ES: %04x\n",
> 		0xffff & regs->xds,0xffff & regs->xes);
>
> -	__asm__("movl %%cr0, %0": "=r" (cr0));
> -	__asm__("movl %%cr2, %0": "=r" (cr2));
> -	__asm__("movl %%cr3, %0": "=r" (cr3));
> -	/* This could fault if %cr4 does not exist */
> -	__asm__("1: movl %%cr4, %0		\n"
> -		"2:				\n"
> -		".section __ex_table,\"a\"	\n"
> -		".long 1b,2b			\n"
> -		".previous			\n"
> -		: "=r" (cr4): "0" (0));
> +	cr0 = read_cr0();
> +	cr2 = read_cr2();
> +	cr3 = read_cr3();
> +	if (current_cpu_data.x86 > 4) {
> +		cr4 = read_cr4();
> +	}
> 	printk("CR0: %08lx CR2: %08lx CR3: %08lx CR4: %08lx\n", cr0, cr2, cr3, cr4);
> 	show_trace(NULL, &regs->esp);
> }
>
> disables code to retrieve the actual value of CR4 on 486-class systems
> (which may or may not implement the register, depending on the exact CPU
> type and stepping).  This seems suspicious to me, but I have to admit I
> haven't followed the discussion on the issue if there was any.
>  

This was deliberate.  CR4 doesn't exist on standard 486 class systems, 
and I'm not sure how you could make use of it anyway, since the features 
used by Linux - machine check, page size extensions, time stamp counter, 
global pages, are only available in Pentium and later class systems, and 
identified by CPUID, which also doesn't exist on 486.

There may be some funky Cyrix or even Intel CPUs that have CR4 
registers, but showing the output in a register dump seems very 
useless.  I would also not recommend using undocumented features in CR4 
even if you have such a freaky processor - there were bugs and/or 
missing functionality with the early large page and global page 
extensions that were not ironed out until the features became 
documented, IIRC.  YMMV - please let me know if anyone has found ways to 
make this useful.

If I am wrong, I am happy to correct this, but I would like to do so 
properly by adding safe_read_cr4() or equivalent rather than using raw 
inlines assembler to catch the fault.

Thanks,

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/