Re: [all better] Re: regression: massive trouble with fpu rework

[Borislav Petkov]

On Mon, Jun 29, 2015 at 11:35:04AM +0200, Ingo Molnar wrote:
> I wish that 'unmasking' logic came with more comments:
> 
>   - Why do BIOSen ever mask CPUIDs?

Doesn't say a thing why:

066941bd4eeb ("x86: unmask CPUID levels on Intel CPUs")

SDM doesn't say why either:

"Limit CPUID Maxval (R/W)

When this bit is set to 1, CPUID.00H returns a maximum value in EAX[7:0]
of 3. BIOS should contain a setup question that allows users to specify
when the installed OS does not support CPUID functions greater than 3.

...

Setting this bit may cause unexpected behavior in software that depends
on the availability of CPUID leaves greater than 3."

In the case of hiding XSAVE from windoze ninety-old, probably something
was exploding there, there wasn't a fix to the software so the hardware
had to become soft.

Purely hypothetical, of course.

The last sentence from the SDM quote above also explains why the Linux
workaround of clearing that bit again, exists.

>   - Why do we unmask the masking?

Also purely hypothetical: because Linux doesn't have the windoze
problem.

>   - Why doesn't the kernel keep on working just fine even if certain
>   CPUID aspects are turned off?

I guess that should be doable but one has to get such a box, enable
that BIOS feature and fix all the fallout that happens. Provided it
can be fixed. hpa went and reenabled those CPUID leafs instead in
066941bd4eeb1.

I guess we simply shouldn't do any CPUID-dependent stuff before:

        if (this_cpu->c_early_init)
                this_cpu->c_early_init(c);

and slap a big fat comment above it.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/