All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas@tungstengraphics.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Support for i386 PATs
Date: Sat, 27 Jan 2007 10:20:18 +0100	[thread overview]
Message-ID: <45BB1952.8000903@tungstengraphics.com> (raw)

Hi!

Does anybody have a strong opinion against adding support for
i386 Page Attribute Tables?

The main benefit would be that one can have write-combining memory
regions without setting up MTRRs. This will come in handy for a
device we're working with where the device driver needs to allocate the
display memory directly from system memory, and it may be difficult to fit
the mtrr alignment constraints.

Outline:
The PAT may be set up at boot time with fixed backwards-compatible
memory types for the different PAT entries + defines like the following:

#define _PAGE_PAT_WB   xxx
#define _PAGE_PAT_WT   xxx
#define _PAGE_PAT_UC0 xxx
#define _PAGE_PAT_UC1 xxx
#define _PAGE_PAT_WC   xxx

which can be used in parallel with the old _PAGE_PWT and _PAGE_PCD bits.

The idea is that new memory types, WC for example, will use the pat entries
7 downto 4, whereas 0-3 are left to boot setting to maintain backwards 
compatibility.

Issues:
1) The _PAGE_BIT_PAT will be the same as _PAGE_PSE, and _PAGE_PROTNONE.
As I understand it, _PAGE_PROTNONE is not used when the page is present, 
so this might not be an issue.
What about _PAGE_PSE?

2) The PATs need to be setup for each processor just after system boot.
Where is the best place to do this?

/Thomas Hellström



             reply	other threads:[~2007-01-27  9:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-27  9:20 Thomas Hellström [this message]
2007-01-27  9:33 ` Support for i386 PATs Avi Kivity
2007-01-28 21:48 ` Dave Jones
2007-01-30 15:50   ` Thomas Hellström
  -- strict thread matches above, loose matches on Subject: below --
2007-01-27 10:59 Mikael Pettersson
2007-01-28  7:54 ` H. Peter Anvin

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=45BB1952.8000903@tungstengraphics.com \
    --to=thomas@tungstengraphics.com \
    --cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.