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

[Ingo Molnar <mingo@kernel.org>]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 06/29/2015 02:35 AM, Ingo Molnar wrote:
> > 
> > Indeed, I bet that makes a difference!
> > 
> > I wish that 'unmasking' logic came with more comments:
> > 
> >   - Why do BIOSen ever mask CPUIDs?
> > 
> 
> To work around bugs in legacy operating systems.
>
> >   - Why do we unmask the masking?
> 
> Because we don't have those specific bugs.

Great - would be nice to put those reasons between /* */ markers, to keep future 
generations (and overworked maintainers!) from wondering.

> >   - Why doesn't the kernel keep on working just fine even if certain CPUID aspects 
> >     are turned off?
> 
> Because it exercises code paths that are otherwise impossible, for example, it 
> exposes the XSAVE capability without exposing the XSAVE information in higher 
> CPUID leaves.
> 
> The other option would be to have a list of CPU features that should be turned 
> off whenever the CPUID leaf maximum is too low, but it gives a better user 
> experience to just override the BIOS capping and then we have fewer code paths 
> in the kernel to worry about.

1)

As a side note, I think we should generally be robust enough to recognize pretty 
much any CPUID 'mischief' and at minimum not crash.

2)

But this FPU crash is different, here the reason for the crash is the following 
bug in the FPU code:

	fpu__init_system(); /* inits the FPU based on masked CPUID */

	... CPUID *extends* ...

	fpu__init_cpu(); /* Actually uses the FPU now based on the expanded CPUID */

        *KABOOM*

I.e. we (obviously) should not base half on the FPU logic on different CPUID bits 
than the other half of the FPU logic.

I'll queue up the fix, which is to do the early FPU init after our CPUID state 
stabilizes. (i.e. the second patch I sent to Mike.)

Thanks,

	Ingo