Message-ID: <1437665107.3214.310.camel@hp.com>
Subject: Re: [PATCH] x86, pat: Add comments to cachemode translation tables
From: Toshi Kani <toshi.kani@hp.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: peterz@infradead.org, mingo@kernel.org, x86@kernel.org, tglx@linutronix.de,
        bp@suse.de, linux-kernel@vger.kernel.org
Date: Thu, 23 Jul 2015 09:25:07 -0600
In-Reply-To: <55B11B4D0200007800094AE9@prv-mh.provo.novell.com>
References: <1437588371-28223-1-git-send-email-toshi.kani@hp.com>
	 <55B0A9110200007800094558@prv-mh.provo.novell.com>
	 <1437661620.3214.281.camel@hp.com>
	 <55B11B4D0200007800094AE9@prv-mh.provo.novell.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2943
Lines: 65

On Thu, 2015-07-23 at 08:50 -0600, Jan Beulich wrote:
> > 
> > > > On 23.07.15 at 16:27, <toshi.kani@hp.com> wrote:
> > On Thu, 2015-07-23 at 00:42 -0600, Jan Beulich wrote:
> > > > 
> > > > > > On 22.07.15 at 20:06, <toshi.kani@hp.com> wrote:
> > > > Add comments to the cachemode translation tables to clarify that
> > > > the default values are set as minimal supported mode, which are
> > > > necessary to handle WC and WT fallback to UC- when they are not
> > > > enabled.
> > > 
> > > Wait - shouldn't WT fall back to UC (so to not be affected by WC
> > > MTRR settings)?
> > 
> > Well, when MTRR is set to WC, WT will become UC.  So, it is not safe to
> > start with.
> 
> Hmm, considering how my question was meant, your reply looks
> contradictory to me. What I was talking about is the table as it is
> in RC3, i.e. WT mapping to PAGE_PCD (matching WC and
> UC_MINUS). I.e. if a page is mapped WT (i.e. UC-) and the
> MTRRs for it say WC, then the result will be WC. Whereas if
> WT translated to PAGE_PWT|PAGE_PCD (i.e. matching UC), an
> MTRR setting of WC would have no effect - the resulting type
> would still be UC.

Yes, I know what you meant.  I agree that WT should fall back to UC when
considering MTRR. 

In my reply, I was referring the regular case that WT is supported (i.e. no
fallback).  WT request to a range covered by MTRR with WC will become UC. 
 I think such code is not written properly (I should not have said "not
safe") since it won't get WT in the regular case, either.  A range with
MTRR covered by WC is a special memory, ex. frame buffer, and the code
should know what type of memory it is dealing with.

> > I know Luis is driving to support UC.  When UC can be used for both 
> > regular
> > memory and IO memory, yes, it can be changed to fall back to UC.  At 
> > this
> > point, however, UC cannot be set to regular memory.  See
> > reserve_ram_pages_type().
> 
> With the above in mind, that's a problem then I would say.
> Yet no matter whether UC can't be expressed as an
> attribute on a page, what gets stored in the page table
> entries should, together with how PAT is set, result in
> something that doesn't weaken the requested memory
> type. I.e. if WT was requested, the end result shouldn't
> be WC. Yet any representable type may still be mapped to
> UC (as being the strictest one possible), and hence if WT
> can't be expressed it should be made UC.

Yes, I agree with you.  But such risk is very low -- 1) the regular case
(no fallback) is used most of the cases, 2) the code using WT knows what
type of memory it is dealing with.  For example, pmem may map NVDIMM with
WT, and any sane BIOS sets MTRR to WB for NVDIMM. 

Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/