From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752766Ab2APAIj (ORCPT ); Sun, 15 Jan 2012 19:08:39 -0500 Received: from terminus.zytor.com ([198.137.202.10]:42004 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751045Ab2APAIi (ORCPT ); Sun, 15 Jan 2012 19:08:38 -0500 Message-ID: <4F136A50.80203@zytor.com> Date: Sun, 15 Jan 2012 16:07:44 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Brian Gerst CC: Fenghua Yu , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Andrew Morton , Asit K Mallick , Tony Luck , Arjan van de Ven , Suresh B Siddha , Len Brown , Randy Dunlap , "Srivatsa S. Bhat" , Konrad Rzeszutek Wilk , Peter Zijlstra , Chen Gong , linux-kernel , linux-pm , x86 Subject: Re: [PATCH v5 10/12] x86/mtrr/main.c: Ask the first online CPU to save mtrr References: <1326301493-28760-1-git-send-email-fenghua.yu@intel.com> <1326301493-28760-11-git-send-email-fenghua.yu@intel.com> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/12/2012 04:33 AM, Brian Gerst wrote: > On Wed, Jan 11, 2012 at 12:04 PM, Fenghua Yu wrote: >> From: Fenghua Yu >> >> Ask the first online CPU to save mtrr instead of asking BSP. BSP could be >> offline when mtrr_save_state() is called. > > If you can use any non-boot cpu to save the MTRRs why not just use the > current cpu? They should all be in sync anyways. > A much bigger question: why do we ever bother saving the MTRR state per se? We examine the MTRR state -- we have to -- during boot, and it should never diverge from the state set by the OS from that point on -- we'll need to set it back to that. So we should just keep track of what the correct MTRR state is at all times. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.