Re: WT memory type on x86_64?

[Stefan Bader]

On 08.05.2013 16:35, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 24, 2013 at 12:33:33PM -0700, Andy Lutomirski wrote:
>> For an upcoming (and, sadly, NDA'd [1]) project, I may need to use
>> write-through memory.  I'd like to gauge how unpleasant this will be.
>>
>> AFAICT, modern CPUs allow the WT type to be set using MTRR or a PAT
>> entry.  Sadly, MTRRs are in short supply, and the four fully-usable
>> PAT slots are used for UC, UC-, WB, and WC.  I can keep my fingers
>> crossed and hope that there are enough free MTRRs, or I could try to
>> free up a PAT entry.
>>
>> How nasty will the latter be?  I just looked at two rather different
>> modern Sandy Bridge machines, and BIOS doesn't appear to set up any
>> MTRRs in the WC or WP states.  As long as those MTRR types aren't
>> used, I think the UC- PAT entry is useless -- it behaves identically
>> to UC.  Lots of DRM drivers, though, seen to add a WC MTRR to cover
>> video memory.  Is there any need for this on modern machines?  That
>> is, are there any drivers that actually need the mtrr_add call to
>> succeed on a machine that has a working PAT?
>>
>> If not, then here's a proposal:  At startup, if there are no WC or WP
>> MTRRs and the CPU is new enough, then set a flag for an alternative
>> PAT.  In alternative PAT mode, UC- is replaced with WT in the PAT and
>> mtrr_add fails when attempting to add a WC or WP entry.  Add
>> set_memory_wt, etc.  They fail in non-alternative-PAT mode.  This gets
>> a bit unpleasant, since _PAGE_CACHE_UC_MINUS will have a different
>> meaning depending on the mode.
>>
>> A less conservative proposal would be to stop using UC- in the PAT
>> entirely.  The memtype code could learn to emulate UC- when there's an
>> overlapping WC or WP MTRR.
>>
>> Any thoughts?  Are there known errata here?  Is there a good reason
>> why the kernel needs UC-?  Will this be such a big can of worms that I
>> should just hope there's an available MTRR?
> 
> Stefan Bader (CC-ed here) was looking in making a "black-box" type
> code wherein for any types but WC it would lookup in the PAT index
> the right bit and provide that for the page_attr_set functions.
> 
> If I recall he had run in a bit of issue with of the hard-coded values
> set by the macros.

It could be opening a can of worms. Right now there are many places / defines
that are based on the assumption that a certain combination of PCD and PWT in
pgprot maps to a certain cache type. PAT is deliberately left out because its
location changes for large pages (PAT and PSE share the same bit). That is the
reason for the PAT MSR is set in a way that results in the same cache type
regardless of the PAT bit being 0 or 1.

Not sure whether this is the reason but UC and UC- (as well as WB) are kept like
the backward compatible setup. So for systems with and without PAT cache types
map to the same. Only WT gets replaced by WC. For that whenever PCD is set it
means some uncached type.

> 
>>
>> --Andy
>>
>> [1]  I hope to be able to upstream all kernel code related to this
>> project.  It will be neat -- I promise.  It will depend on convincing
>> the people on the other end of the NDA that they should let me.
>> --
>> 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/
>>

Attachment: signature.asc
Description: OpenPGP digital signature