[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60179b8d-319d-8860-a599-29577fb9fe26@ce.jp.nec.com>
Date: Wed, 31 May 2017 09:39:03 +0000
From: Junichi Nomura <j-nomura@...jp.nec.com>
To: Mikulas Patocka <mpatocka@...hat.com>
CC: Dominik Brodowski <linux@...inikbrodowski.net>,
Bernhard Held <berny156@....de>,
Andy Lutomirski <luto@...nel.org>,
Toshi Kani <toshi.kani@...com>, Borislav Petkov <bp@...en8.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Brian Gerst <brgerst@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, "Ingo Molnar" <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Peter Zijlstra" <peterz@...radead.org>,
"Luis R. Rodriguez" <mcgrof@...e.com>,
"Denys Vlasenko" <dvlasenk@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that
don't support PAT
On 05/31/17 02:59, Mikulas Patocka wrote:
>>> 2. use the PAT patch and revert the change to the function pat_ap_init
>>> - i.e. change it to the original:
>>> static void pat_ap_init(u64 pat)
>>> {
>>> if (!boot_cpu_has(X86_FEATURE_PAT)) {
>>
>> Joy.
>
> It is interesting - does it mean that the boot cpu does have PAT and the
> secondary CPUs don't?
It seems pat_init() is called twice for boot cpu, from mtrr_bp_pat_init()
and generic_set_all(). The 2nd call ends up calling pat_ap_init() and it's
before boot_cpu_data is copied to cpu_data[0].
--
Jun'ichi Nomura, NEC Corporation / NEC Solution Innovators, Ltd.
Powered by blists - more mailing lists