On Tue, Aug 03, 2004 at 06:05:42PM -0500, Josh Boyer wrote:
Howdy,
In 2.6, the PPC mm code for 4xx platforms uses large TLB entries for
most of RAM. Specifically, I am looking at arch/ppc/mm/4xx_mmu.c at the
mmu_mapin_ram function. In there, the pmd pointers are setup with
_PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE.
Doesn't this allow the text pages of the kernel to be written to? So to
Yes.
my understanding, a buggy driver that went off into the weeds could
corrupt the text pages of the kernel.
Yes.
I would think that you would want the kernel text pages to be
non-writable so that if something like the above scenario happened you
don't have possibly bad text pages. Debugging wouldn't be much fun.
Ideally, that's true. However, the kernel lowmem large TLB mapping is
there for performance. There's no way to manage default page size
protection on the text pages. It's a tradeoff between performance
and the ease of debugging a misguided driver. With all the kernel
debugging tools these days, it sure seems like performance is the
clear winner.
I think I am missing something here. If so, please excuse my lack of
knowledge on TLBs, but I am somewhat new to the low level stuff. Anyone
care to point out what I am missing?
Well, it should be noted that the Classic PPC mapin_ram does a similar
thing. When mapping with BATs, the ability to do per (default size) page
RO is not available. For reasons of performance, this is the default
method to map kernel lowmem on Classic PPC cores.
The same situation is present on Book E parts (44x/85xx). Since they
map all of kernel lowmem staticly with large TLB entries, they also
lack the ability to cover kernel text with read-only entries.
Anyway, this isn't just 4xx, it's pretty much everywhere. It's
possible to make 4xx large TLB mapping optional, but it's not
clear that adding the option is really that useful (at least
to me, YMMV).
-Matt
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Tue, 2004-08-03 at 19:16, Matt Porter wrote:
quoted
I would think that you would want the kernel text pages to be
non-writable so that if something like the above scenario happened you
don't have possibly bad text pages. Debugging wouldn't be much fun.
Ideally, that's true. However, the kernel lowmem large TLB mapping is
there for performance. There's no way to manage default page size
protection on the text pages. It's a tradeoff between performance
and the ease of debugging a misguided driver. With all the kernel
debugging tools these days, it sure seems like performance is the
clear winner.
Well at least my understanding of what was going on was right :). I see
the tradeoff, I was just wondering if there was some happy medium.
Maybe pinning a read-only TLB entry for most of the text pages for
however large you can get would work... or maybe not.
It's probably not that large of an issue for a normal user because the
kernel and drivers are fairly stable, which makes performance more
important. But when someone is writing new drivers, randomly poking
holes in the kernel text pages and then executing instructions from
there leads to some strange panics. Although, the new driver should be
suspect in that case anyway :).
quoted
I think I am missing something here. If so, please excuse my lack of
knowledge on TLBs, but I am somewhat new to the low level stuff. Anyone
care to point out what I am missing?
Well, it should be noted that the Classic PPC mapin_ram does a similar
thing. When mapping with BATs, the ability to do per (default size) page
RO is not available. For reasons of performance, this is the default
method to map kernel lowmem on Classic PPC cores.
The same situation is present on Book E parts (44x/85xx). Since they
map all of kernel lowmem staticly with large TLB entries, they also
lack the ability to cover kernel text with read-only entries.
Anyway, this isn't just 4xx, it's pretty much everywhere. It's
possible to make 4xx large TLB mapping optional, but it's not
clear that adding the option is really that useful (at least
to me, YMMV).
Yeah, I figured it was more than just 40x, it's just that is what I am
using right now. Thanks for the info.
josh
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Aug 4, 2004, at 7:49 AM, Josh Boyer wrote:
Maybe pinning a read-only TLB entry for most of the text pages for
however large you can get would work... or maybe not.
The problem is BATs and pinned TLBs require alignment restrictions
that don't allow this.
.....But when someone is writing new drivers, randomly poking
holes in the kernel text pages and then executing instructions from
there leads to some strange panics. Although, the new driver should be
suspect in that case anyway :).
Then, on MPC8xx don't select pinned TLBs to cover the kernel
space, and on traditional PPC MMUs select the 'nobat' option
on the command line. This will write protect the kernel text pages.
However, if you select something like CONFIG_KGDB, this will
allow writing of the text pages to set breakpoints. You will need
to use a debugger like the BDI2000 and use hardware breakpoints
to do your debugging. When you are done, you can enable the
performance TLB options again. I thought the 4xx allowed
something like this as well. If not, it could and probably should.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/