linux-kernel - Re: [RFC PATCH 0/11] Support Write-Through mapping on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <03d059f5-b564-4530-9184-f91ca9d5c016@email.android.com>
Date:	Tue, 15 Jul 2014 20:40:28 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Toshi Kani <toshi.kani@...com>, "H. Peter Anvin" <hpa@...or.com>
CC:	tglx@...utronix.de, mingo@...hat.com, akpm@...ux-foundation.org,
	arnd@...db.de, plagnioj@...osoft.com, tomi.valkeinen@...com,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	stefan.bader@...onical.com, luto@...capital.net, airlied@...il.com,
	bp@...en8.de
Subject: Re: [RFC PATCH 0/11] Support Write-Through mapping on x86

On July 15, 2014 5:23:24 PM EDT, Toshi Kani <toshi.kani@...com> wrote:
>On Tue, 2014-07-15 at 13:09 -0700, H. Peter Anvin wrote:
>> On 07/15/2014 12:34 PM, Toshi Kani wrote:
>> > This RFC patchset is aimed to seek comments/suggestions for the
>design
>> > and changes to support of Write-Through (WT) mapping.  The study
>below
>> > shows that using WT mapping may be useful for non-volatile memory.
>> > 
>> >   http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf
>> > 
>> > There were idea & patches to support WT in the past, which
>stimulated
>> > very valuable discussions on this topic.
>> > 
>> >   https://lkml.org/lkml/2013/4/24/424
>> >   https://lkml.org/lkml/2013/10/27/70
>> >   https://lkml.org/lkml/2013/11/3/72
>> > 
>> > This RFC patchset tries to address the issues raised by taking the
>> > following design approach:
>> > 
>> >  - Keep the MTRR interface
>> >  - Keep the WB, WC, and UC- slots in the PAT MSR
>> >  - Keep the PAT bit unused
>> >  - Reassign the UC slot to WT in the PAT MSR
>> > 
>> > There are 4 usable slots in the PAT MSR, which are currently
>assigned to:
>> > 
>> >   PA0/4: WB, PA1/5: WC, PA2/6: UC-, PA3/7: UC
>> > 
>> > The PAT bit is unused since it shares the same bit as the PSE bit
>and
>> > there was a bug in older processors.  Among the 4 slots, the
>uncached
>> > memory type consumes 2 slots, UC- and UC.  They are functionally
>> > equivalent, but UC- allows MTRRs to overwrite it with WC.  All
>interfaces
>> > that set the uncached memory type use UC- in order to work with
>MTRRs.
>> > The PA3/7 slot is effectively unused today.  Therefore, this
>patchset
>> > reassigns the PA3/7 slot to WT.  If MTRRs get deprecated in future,
>> > UC- can be reassigned to UC, and there is still no need to consume
>> > 2 slots for the uncached memory type.
>> 
>> Not going to happen any time in the forseeable future.
>> 
>> Furthermore, I don't think it is a big deal if on some old, buggy
>> processors we take the performance hit of cache type demotion, as
>long
>> as we don't actively lose data.
>> 
>> > This patchset is consist of two parts.  The 1st part, patch [1/11]
>to
>> > [6/11], enables WT mapping and adds new interfaces for setting WT
>mapping.
>> > The 2nd part, patch [7/11] to [11/11], cleans up the code that has
>> > internal knowledge of the PAT slot assignment.  This keeps the
>kernel
>> > code independent from the PAT slot assignment.
>> 
>> I have given this piece of feedback at least three times now,
>possibly
>> to different people, and I'm getting a bit grumpy about it:
>> 
>> We already have an issue with Xen, because Xen assigned mappings
>> differently and it is incompatible with the use of PAT in Linux.  As
>a
>> result we get requests for hacks to work around this, which is
>something
>> I really don't want to see.  I would like to see a design involving a
>> "reverse PAT" table where the kernel can hold the mapping between
>memory
>> types and page table encodings (including the two different ones for
>> small and large pages.)
>
>Thanks for pointing this out! (And sorry for making you repeat it three
>time...)  I was not aware of the issue with Xen.  I will look into the
>email archive to see what the Xen issue is, and how it can be
>addressed.

https://lkml.org/lkml/2011/11/8/406
>
>Thanks,
>-Toshi


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