Date: Tue, 30 Jun 2015 07:14:16 +0200
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@alien8.de>, Mike Galbraith <umgwanakikbuti@gmail.com>,
        Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Denys Vlasenko <dvlasenk@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
        Dave Hansen <dave@sr71.net>
Subject: Re: [all better] Re: regression: massive trouble with fpu rework
Message-ID: <20150630051416.GA5782@gmail.com>
References: <1435386316.3664.23.camel@gmail.com>
 <1435393129.3490.7.camel@gmail.com>
 <20150627082514.GA10894@gmail.com>
 <1435395328.6545.10.camel@gmail.com>
 <20150629064008.GA16251@gmail.com>
 <1435566329.2900.1.camel@gmail.com>
 <20150629083302.GA13113@pd.tnic>
 <20150629093504.GA20600@gmail.com>
 <5591A103.6020104@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5591A103.6020104@zytor.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2053
Lines: 65


* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/