Re: Page Attribute Table (PAT) support?

Jeff Hartmann (jhartmann@valinux.com)
Wed, 24 Jan 2001 14:15:32 -0700


Timur Tabi wrote:

> ** Reply to message from Jeff Hartmann <jhartmann@valinux.com> on Wed, 24 Jan
> 2001 13:41:41 -0700
>
>
>> When you mark a page UCWC, you better
>> have removed all cached mappings or your asking for REAL trouble.
>
>
> What exactly do you mean by "removed all cached mappings"? Does that mean that
> if one virtual address is a UCWC mapping of a physical page, then ALL virtual
> addresses mapped to that page must also be UCWC?
>
> In my driver, I use ioremap_nocache() on physical memory (real RAM) to create
> an uncached "alias" (a virtual address) to a physical page of RAM. When I
> access the memory via this virtual address, the memory access is not cached.
> What I reall need is to be able to also have that virtual address as Write
> Combined.

Pages with multiple mappings aren't really supported by the Intel ia32
architecture. The trick you do above works, but is strongly discouraged
by the Intel documentation. The documentation says that if you do this
with UCWC memory, it won't work (and will result in undefined processor
behavior.) My experiments with the PAT seem to agree with the
documentation.

>
> Since all physical RAM is mapped as cached via the kernel (on a 1-to-1 basis),
> and since there can be several other virtual addresses that point to that memory
> (e.g. user virtual address), I can't see how these virtual addresses can be
> removed.

We have to remove the kernel page table mappings. (Convert the 4MB pages
to individual pte's, then change the individual pte so its pgprot value
is correct.)

When you allocate memory in the kernel, you OWN it. Its not mapped into
a user space process unless you put it there. I have to point out that
this interface requires the user to insure these pages are never ever
swapped, or mapped cached. This isn't a huge restriction, since we
aren't providing a user land interface. If we try to handle all/some of
these cases in the kernel, it becomes a very large problem. We would
have to add arch specific bits for special cache handling, Do smp cache
flushes all over the place, etc. Its really not worth it.

-Jeff

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