From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752657AbbDBU3Q (ORCPT ); Thu, 2 Apr 2015 16:29:16 -0400 Received: from mail-qc0-f178.google.com ([209.85.216.178]:34096 "EHLO mail-qc0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751548AbbDBU3M (ORCPT ); Thu, 2 Apr 2015 16:29:12 -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: Bjorn Helgaas Date: Thu, 2 Apr 2015 15:28:51 -0500 Message-ID: Subject: Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR To: "Luis R. Rodriguez" 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 3:20 PM, Luis R. Rodriguez wrote: > 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. Your text is missing some words. You seem to be using "up" as a verb, but it's not a verb. Maybe you meant "end up"? Even then, it wouldn't make sense for CONFIG_MTRR to be "disabled at run time" because CONFIG_MTRR is a compile-time switch. The MTRR *functionality* could certainly be disabled at run-time, but not CONFIG_MTRR itself. >> 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. "CONFIG_X86_PAT continues to kick through" doesn't seem a very precise way of describing this. But maybe it's enough for experts in this area (which I'm not). Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Date: Thu, 02 Apr 2015 20:28:51 +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: "Luis R. Rodriguez" 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 3:20 PM, Luis R. Rodriguez wrote: > 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. Your text is missing some words. You seem to be using "up" as a verb, but it's not a verb. Maybe you meant "end up"? Even then, it wouldn't make sense for CONFIG_MTRR to be "disabled at run time" because CONFIG_MTRR is a compile-time switch. The MTRR *functionality* could certainly be disabled at run-time, but not CONFIG_MTRR itself. >> 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. "CONFIG_X86_PAT continues to kick through" doesn't seem a very precise way of describing this. But maybe it's enough for experts in this area (which I'm not). Bjorn From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR Date: Thu, 2 Apr 2015 15:28:51 -0500 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: "Luis R. Rodriguez" 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 3:20 PM, Luis R. Rodriguez wrote: > 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. Your text is missing some words. You seem to be using "up" as a verb, but it's not a verb. Maybe you meant "end up"? Even then, it wouldn't make sense for CONFIG_MTRR to be "disabled at run time" because CONFIG_MTRR is a compile-time switch. The MTRR *functionality* could certainly be disabled at run-time, but not CONFIG_MTRR itself. >> 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. "CONFIG_X86_PAT continues to kick through" doesn't seem a very precise way of describing this. But maybe it's enough for experts in this area (which I'm not). Bjorn