On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez <[email protected]> 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? And "... continues to kick through"? Probably some idiomatic
usage I'm just too old to understand :)
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.
Bjorn
On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas <[email protected]> wrote:
>
> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez <[email protected]> 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
On Thu, Apr 2, 2015 at 3:20 PM, Luis R. Rodriguez <[email protected]> wrote:
> On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas <[email protected]> wrote:
>>
>> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez <[email protected]> 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
On Thu, Apr 02, 2015 at 03:28:51PM -0500, Bjorn Helgaas wrote:
> On Thu, Apr 2, 2015 at 3:20 PM, Luis R. Rodriguez <[email protected]> wrote:
> > On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas <[email protected]> wrote:
> >>
> >> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez <[email protected]> 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"?
Indeed.
> 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.
I'll clarify.
> >> 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).
I've rephrased this to:
---
It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT
and end up with a system with MTRR functionality disabled
PAT functionality enabled. This can happen for instance
on Xen where MTRR is not supported but PAT is. This can
happen on Linux as of commit 47591df50 ("xen: Support Xen
pv-domains using PAT") by Juergen, introduced as of v3.19.
---
Luis
On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez <[email protected]> wrote:
> ---
> It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT
> and end up with a system with MTRR functionality disabled
> PAT functionality enabled.
This is missing a conjunction or something in "MTRR functionality
disabled PAT functionality."
Bjorn
On Thu, Apr 2, 2015 at 3:09 PM, Bjorn Helgaas <[email protected]> wrote:
> On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez <[email protected]> wrote:
>
>> ---
>> It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT
>> and end up with a system with MTRR functionality disabled
>> PAT functionality enabled.
>
> This is missing a conjunction or something in "MTRR functionality
> disabled PAT functionality."
"and PAT functionality" -- fixed. Thanks.
Luis