Re: [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR
From: Bjorn Helgaas
Date: Thu Apr 02 2015 - 16:29:19 EST
On Thu, Apr 2, 2015 at 3:20 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> 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"
> 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
>> 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).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/