linux-kernel - Re: questions about x86: mtrr cleanup for converting continuous to discrete layout

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-next>] [day] [month] [year] [list]

Message-ID: <47ed01bd0809291546q4d0dc85fif46667b75bfb7526@mail.gmail.com>
Date:	Mon, 29 Sep 2008 18:46:23 -0400
From:	"Dylan Taft" <d13f00l@...il.com>
To:	linux-kernel@...r.kernel.org, yinghai@...nel.org, hugh@...osa.com
Subject: Re: questions about x86: mtrr cleanup for converting continuous to discrete layout

I think a workaround in the kernel is absolutely necessary.  A lot of
newer motherboards have this issue, where a whole section of memory
will be marked as write-back, and write-combining can't be
embedded/nested.
As far as I'm aware, changing MTRRs won't make a system unstable,
especially if done so early on, when the kernel is starting up.  All
it does is change the behavior on how the CPU will cache write
requests to memory.  All system memory should be marked as write-back,
how many MTRRs are used to do this...I'm not sure if it exactly
matters.  You can set MTRR_SPARE_REG_NR and control how many MTRR
slots the code will use.

Is it legal to mark a write-combining range within a write-back range?

Ideally, maybe adding a minimal amount of MTRRs might be best, as D.
Hugh Redelmeier's userspace app does, but I think a fix for this in
the _kernel_ is an absolute must for 2.6.27.  Weather a range that has
to be marked for write-combining is just "uncovered", or weather
ranges are entirely automatically generated in chunks, either should
work, but Hugh's suggestion might save MTRR entries in practice?

I'm no kernel dev, I code a bit here and there, but I spent a LOT of
time researching this when I ran into the problem myself on my new PC.
 There's a lot of posts about it too in the intel bug tracker for
people with newer boards and the g45 chipset.  Most users shouldn't
have to worry about this, and it should, "just work".

I don't think this should be pulled unless a different fix is in place
in the kernel.

Thanks!

Here's what bios does with my MTRRs, write combining can't be set up
for my video card
reg00: base=0x1b0000000 (6912MB), size= 256MB: uncachable, count=1
reg01: base=0x1c0000000 (7168MB), size=1024MB: uncachable, count=1
reg02: base=0x00000000 (   0MB), size=8192MB: write-back, count=1
reg03: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg04: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg05: base=0xc7e00000 (3198MB), size=   2MB: uncachable, count=1
reg06: base=0xc8000000 (3200MB), size= 128MB: uncachable, count=1

and with Yinghai Lu's patches in git tip, with working write-combining mark
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 128MB: write-back, count=1
reg03: base=0xc7e00000 (3198MB), size=   2MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
reg05: base=0x180000000 (6144MB), size= 512MB: write-back, count=1
reg06: base=0x1a0000000 (6656MB), size= 256MB: write-back, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
--
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/