From: Andreas Werner <wernerandy@gmx.de>
To: Borislav Petkov <bp@alien8.de>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, dave@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] X86: MM: Add PAT Type write-through in combination with mtrr
Date: Sun, 27 Oct 2013 17:51:59 +0100 [thread overview]
Message-ID: <20131027165159.GD1617@thinkpad.fritz.box> (raw)
In-Reply-To: <20131027133401.GB24817@pd.tnic>
On Sun, Oct 27, 2013 at 02:34:01PM +0100, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 01:55:25PM +0100, Andreas Werner wrote:
> > This patch adds the Write-through memory type in combination with mtrr.
> > If you call ioremap_cache to request cachable memory (write-back) the
> > function tries to set the PAT to write-back only if the mtrr setting of
> > the requested region is also marked as Write-Back.
> > If the mttr regions are marked e.g. as Write-through or with other
> > types, the function will always return UC- memory.
> >
> > If you check the Intel document " IA-32 SDM vol 3a table Effective
> > Memory Type", there
> > are many other combinations possible.
> >
> > This patch will only add the following combination:
> > PAT=Write-Back + MTRR=Write-Through = Effective Memory of
> > Write-Through
>
> And yet the code below returns WB for WT MTRR type which can't be
> right since having a write-through mapping cannot be compatible with
> write-back as the last caches writes into the cache instead of writing
> them through to memory.
>
> Why do you even care about WT? Are you trying to fix a bug or what?
>
Im currently working on an ethernet driver for our own ETH core.
The problem is that one requirement is to not use DMA to transmit
or receive the data. This means the that the ethernet buffers are not
located in the main memory. They are located in the FPGA internal RAM.
To transmit or receive a frame, i have to read or write to mmio to get the data.
Intel has introduced the instruction "clflush" which can flush a cache line.
I want to use the caches for those mmio (eth buffer) to speed up the transmit/receive
and to transmit/receive using PCIe bursts (read/write).
The problem was if i set the buffer to Write-Back and call clflush on
those mmio-addresses, the system crashed without any output.
I found this articel
http://software.intel.com/en-us/forums/topic/393070
After that i configured the transmit buffers to be Write-Combining (only write to that adresses)
using ioremap_wc, and the receive buffers to be Write-Through (ioremap_cache + mtrr Write-Through + this kernel patch)
everything worked as expected.
On PCIe Tracer i can see the bursts on read/write on my device with this configuration.
I know that this is a special use case but there is also one person more out there,
who use that configuration. But why not allow this setting in the kernel? It is
also mentioned in the Intel IA32 document.
I know that there is also an instruction called "movntdqa" but this is not support on my platform
(Intel E680) this instruction was introduced in SSE3. So i can not use it.
If you need more detailed informations please ask me.
Best Regards
Andy
> > Tested on - Intel (R) Atom E680 (Tunnel Creek)
> > - Intel (R) Core(TM)2 Duo
> >
> > Signed-off-by: Andreas Werner <wernerandy@gmx.de>
> > ---
> > arch/x86/mm/pat.c | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> > index 6574388..9cfe107 100644
> > --- a/arch/x86/mm/pat.c
> > +++ b/arch/x86/mm/pat.c
> > @@ -149,10 +149,15 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end, unsigned long req_type)
> > u8 mtrr_type;
> >
> > mtrr_type = mtrr_type_lookup(start, end);
> > - if (mtrr_type != MTRR_TYPE_WRBACK)
> > - return _PAGE_CACHE_UC_MINUS;
> >
> > - return _PAGE_CACHE_WB;
> > + switch (mtrr_type) {
> > + case MTRR_TYPE_WRBACK:
> > + case MTRR_TYPE_WRTHROUGH:
> > + return _PAGE_CACHE_WB;
> > +
> > + default:
> > + return _PAGE_CACHE_UC_MINUS;
> > + }
> > }
> >
> > return req_type;
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
next prev parent reply other threads:[~2013-10-27 16:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-27 12:55 [PATCH] X86: MM: Add PAT Type write-through in combination with mtrr Andreas Werner
2013-10-27 13:34 ` Borislav Petkov
2013-10-27 16:51 ` Andreas Werner [this message]
2013-10-27 17:31 ` Borislav Petkov
2013-10-27 17:56 ` Andreas Werner
2013-10-27 19:01 ` Borislav Petkov
2013-10-28 6:29 ` Andreas Werner
2013-10-28 10:17 ` Ingo Molnar
2013-10-28 10:29 ` Borislav Petkov
2013-10-28 10:31 ` Ingo Molnar
2013-10-28 10:44 ` Borislav Petkov
2013-10-28 10:45 ` Andreas Werner
2013-10-28 10:51 ` Ingo Molnar
2013-10-28 10:53 ` H. Peter Anvin
2013-10-28 11:02 ` Andreas Werner
2013-10-28 10:31 ` H. Peter Anvin
2013-10-28 10:34 ` Andreas Werner
2013-10-28 10:57 ` Borislav Petkov
2013-10-28 11:25 ` Andreas Werner
2013-10-28 11:45 ` Borislav Petkov
2013-10-28 12:03 ` Andreas Werner
2013-10-28 13:58 ` Borislav Petkov
2013-10-28 14:19 ` Andreas Werner
-- strict thread matches above, loose matches on Subject: below --
2013-08-25 7:01 Andreas Werner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131027165159.GD1617@thinkpad.fritz.box \
--to=wernerandy@gmx.de \
--cc=bp@alien8.de \
--cc=dave@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).