Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934443AbcCKDxl (ORCPT ); Thu, 10 Mar 2016 22:53:41 -0500 Received: from g4t3427.houston.hp.com ([15.201.208.55]:50922 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934271AbcCKDxW (ORCPT ); Thu, 10 Mar 2016 22:53:22 -0500 From: Toshi Kani To: mingo@kernel.org, bp@suse.de, hpa@zytor.com, tglx@linutronix.de Cc: mcgrof@suse.com, jgross@suse.com, paul.gortmaker@windriver.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/2] Refactor MTRR and PAT initializations Date: Thu, 10 Mar 2016 21:45:44 -0700 Message-Id: <1457671546-13486-1-git-send-email-toshi.kani@hpe.com> X-Mailer: git-send-email 2.5.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1191 Lines: 28 Since 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")', we emulate a PAT table when PAT is disabled. This requires pat_init() be called even if PAT is disabled, which revealed a long standing issue that PAT is left enabled without calling pat_init() at all. pat_init() is called from MTRR code since it relies on MTRR's rendezvous handler to initialize PAT for all APs . However, when CPU does not support MTRR, ex. qemu32's virtual CPU, MTRR is set disabled and does not call pat_init(). There is no interface available for MTRR to disable PAT, either. This patch-set refactors MTRR and PAT initializations to make sure that PAT is properly initialized in all cases. --- Toshi Kani (2): 1/2 x86/mm/pat: Change pat_disable() to emulate PAT table 2/2 x86/mtrr: Refactor PAT initialization code --- arch/x86/include/asm/mtrr.h | 6 ++- arch/x86/include/asm/pat.h | 1 + arch/x86/kernel/cpu/mtrr/generic.c | 24 ++++++----- arch/x86/kernel/cpu/mtrr/main.c | 13 +++++- arch/x86/kernel/cpu/mtrr/mtrr.h | 1 + arch/x86/mm/pat.c | 84 +++++++++++++++++++++++--------------- 6 files changed, 84 insertions(+), 45 deletions(-)