From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752235AbbDBUVS (ORCPT ); Thu, 2 Apr 2015 16:21:18 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:35955 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbbDBUVQ (ORCPT ); Thu, 2 Apr 2015 16:21:16 -0400 MIME-Version: 1.0 In-Reply-To: References: <1426893517-2511-1-git-send-email-mcgrof@do-not-panic.com> <1426893517-2511-3-git-send-email-mcgrof@do-not-panic.com> <20150325195941.GM25884@l.oracle.com> <20150326233555.GE5622@wotan.suse.de> From: "Luis R. Rodriguez" Date: Thu, 2 Apr 2015 13:20:54 -0700 X-Google-Sender-Auth: D8gXaCBFSZvuSsivos6U3fvmQv8 Message-ID: Subject: Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR To: Bjorn Helgaas Cc: Konrad Rzeszutek Wilk , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Juergen Gross , Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , linux-fbdev , "x86@kernel.org" , "xen-devel@lists.xenproject.org" , Ingo Molnar , Daniel Vetter , Antonino Daplas , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Dave Hansen , Stefan Bader , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , David Vrabel , Toshi Kani , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote: > > On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: > > > I'll rephrase this to: > > > > --- > > It is possible to enable CONFIG_MTRR and up with it > > disabled at run time and yet CONFIG_X86_PAT continues > > to kick through with all functionally enabled. This > > can happen for instance on Xen where MTRR is not > > supported but PAT is, this can happen now on Linux as > > of commit 47591df50 by Juergen introduced as of v3.19. > > I still can't parse this. What does "up with it disabled at run time" > mean? It means that technically even if your CPU/BIOS/system did support MTRR if you use a kernel with MTRR support enabled you might end up with a situation where under one situation MTRR might be enabled and at another run time scenario with the same exact kernel and system you will end up with MTRR disabled. Such is the case for example when booting with Xen, which disables the CPU bits on the hypervisor code. If you boot the same system without Xen you'll get MTRR. > And "... continues to kick through"? Probably some idiomatic > usage I'm just too old to understand :) That means for example that in both the above circumstances even if MTRR went disabled at run time with Xen, the kernel went through with getting PAT enabled. > Please use the conventional citation format: > > 47591df50512 ("xen: Support Xen pv-domains using PAT") > > A one-character typo in a SHA1 makes it completely useless, so it's > nice to have the summary line both for readability and a bit of > redundancy. Sure, fixed. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Date: Thu, 02 Apr 2015 20:20:54 +0000 Subject: Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR Message-Id: List-Id: References: <1426893517-2511-1-git-send-email-mcgrof@do-not-panic.com> <1426893517-2511-3-git-send-email-mcgrof@do-not-panic.com> <20150325195941.GM25884@l.oracle.com> <20150326233555.GE5622@wotan.suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Bjorn Helgaas Cc: Konrad Rzeszutek Wilk , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Juergen Gross , Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , linux-fbdev , "x86@kernel.org" , "xen-devel@lists.xenproject.org" , Ingo Molnar , Daniel Vetter , Antonino Daplas , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Dave Hansen , Stefan Bader , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , David Vrabel , Toshi Kani , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote: > > On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: > > > I'll rephrase this to: > > > > --- > > It is possible to enable CONFIG_MTRR and up with it > > disabled at run time and yet CONFIG_X86_PAT continues > > to kick through with all functionally enabled. This > > can happen for instance on Xen where MTRR is not > > supported but PAT is, this can happen now on Linux as > > of commit 47591df50 by Juergen introduced as of v3.19. > > I still can't parse this. What does "up with it disabled at run time" > mean? It means that technically even if your CPU/BIOS/system did support MTRR if you use a kernel with MTRR support enabled you might end up with a situation where under one situation MTRR might be enabled and at another run time scenario with the same exact kernel and system you will end up with MTRR disabled. Such is the case for example when booting with Xen, which disables the CPU bits on the hypervisor code. If you boot the same system without Xen you'll get MTRR. > And "... continues to kick through"? Probably some idiomatic > usage I'm just too old to understand :) That means for example that in both the above circumstances even if MTRR went disabled at run time with Xen, the kernel went through with getting PAT enabled. > Please use the conventional citation format: > > 47591df50512 ("xen: Support Xen pv-domains using PAT") > > A one-character typo in a SHA1 makes it completely useless, so it's > nice to have the summary line both for readability and a bit of > redundancy. Sure, fixed. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR Date: Thu, 2 Apr 2015 13:20:54 -0700 Message-ID: References: <1426893517-2511-1-git-send-email-mcgrof@do-not-panic.com> <1426893517-2511-3-git-send-email-mcgrof@do-not-panic.com> <20150325195941.GM25884@l.oracle.com> <20150326233555.GE5622@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Bjorn Helgaas Cc: Konrad Rzeszutek Wilk , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Juergen Gross , Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , linux-fbdev , "x86@kernel.org" , "xen-devel@lists.xenproject.org" , Ingo Molnar , Daniel Vetter , Antonino Daplas , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Dave Hansen , Stefan Bader List-Id: xen-devel@lists.xenproject.org On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote: > > On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: > > > I'll rephrase this to: > > > > --- > > It is possible to enable CONFIG_MTRR and up with it > > disabled at run time and yet CONFIG_X86_PAT continues > > to kick through with all functionally enabled. This > > can happen for instance on Xen where MTRR is not > > supported but PAT is, this can happen now on Linux as > > of commit 47591df50 by Juergen introduced as of v3.19. > > I still can't parse this. What does "up with it disabled at run time" > mean? It means that technically even if your CPU/BIOS/system did support MTRR if you use a kernel with MTRR support enabled you might end up with a situation where under one situation MTRR might be enabled and at another run time scenario with the same exact kernel and system you will end up with MTRR disabled. Such is the case for example when booting with Xen, which disables the CPU bits on the hypervisor code. If you boot the same system without Xen you'll get MTRR. > And "... continues to kick through"? Probably some idiomatic > usage I'm just too old to understand :) That means for example that in both the above circumstances even if MTRR went disabled at run time with Xen, the kernel went through with getting PAT enabled. > Please use the conventional citation format: > > 47591df50512 ("xen: Support Xen pv-domains using PAT") > > A one-character typo in a SHA1 makes it completely useless, so it's > nice to have the summary line both for readability and a bit of > redundancy. Sure, fixed. Luis