All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Thomas Hellström" <thomas@tungstengraphics.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.sourceforge.net>
Subject: Re: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.
Date: Sun, 06 Apr 2008 12:01:17 -0700	[thread overview]
Message-ID: <47F91DFD.9030508@goop.org> (raw)
In-Reply-To: <47F8DA44.3070008@tungstengraphics.com>

Thomas Hellström wrote:
> Hi!
>
> For a long time now, the agpgart module has been creating illegal 
> mapping aliases, since the user-space mappings of the pages in the 
> gart are usually write-combined, whereas the kernel linear mapping of 
> the same pages are uc for x86, and may even be wb for some architectures.
>
> In order to fix this, and to facilitate fast insertion and removal of 
> pages into / from the gart I'd like to disable all default kernel 
> mappings for those pages, which would in effect, make them behave as 
> highmem pages from our point of view.
>
> As prevously discussed, the x86 set_memory_xxx() interface wasn't 
> suitable for this, since it handles only a single mapping, and the 
> pages may have more than one default kernel mapping.
>
> But it turns out that there is an interface that does exactly this. 
> kernel_map_pages(). But it is only available  with 
> CONFIG_DEBUG_PAGEALLOC. I'd like to make that function exported by 
> default, but with some minor alterations as the original functions 
> does some debug checks as well, that aren't desirable for the purpose 
> mentioned above:
>
> As with highmem pages, if the driver sets up user-space mappings with 
> non-standard caching attributes, those mappings need to be killed at 
> suspend time, since the suspend code would otherwise create temporary 
> incompatible mappings.
>
> On x86 this all would probably work fine. Does kernel_map_pages() work 
> identically on other architectures? Specifically: Will it always work 
> with a 4K page granularity?

Well, not all architectures use 4k as their base page size, but 
kernel_map_pages should work at the smallest supported page size.

The disadvantage of this is that it will end up shattering any 
large-page mappings the kernel has.  This is pretty much unavoidable 
unless you can arrange to only allocate AGP pages in a physically 
distinct area away from other kernel allocations (a mechanism to do this 
might be generally useful, though I'm not sure what form it would take - 
another zone perhaps?).

    J

  reply	other threads:[~2008-04-06 19:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-06 14:12 [RFC] Use kernel_map_pages() to avoid illegal page aliasing Thomas Hellström
2008-04-06 19:01 ` Jeremy Fitzhardinge [this message]
2008-04-06 19:13   ` Thomas Hellström

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=47F91DFD.9030508@goop.org \
    --to=jeremy@goop.org \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@tungstengraphics.com \
    /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.