From: Marcelo Tosatti <marcelo.tosatti@cyclades•com>
To: Dan Malek <dan@embeddededge•com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
Date: Fri, 6 May 2005 17:03:38 -0300 [thread overview]
Message-ID: <20050506200338.GC14486@logos.cnet> (raw)
In-Reply-To: <3ebef94782a6090ac3eb44bd7e78efbf@embeddededge.com>
Hi Dan,
On Fri, May 06, 2005 at 06:49:11PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 9:38 AM, Marcelo Tosatti wrote:
>
> >1) avoids the creation of pte tables in the 8Mbyte range, thus
> >preserving
> >the pinned TLB entry.
>
> This has nothing to do with "preserving" the pinned TLB entry.
> The pinned entries are placed into the reserved portion of the TLB,
> and are never evicted.
OK.
> We never get a fault on these pages, so wenever look up an
> entry in the page table.
The data I have tells me otherwise. I have seen the I-TLB entries
getting created for kernel space.
I did the following:
- insert a break at the beginning of start_kernel, another break at
the end of start_kernel.
- boot, BDI stops at start_kernel.
- dump I-TLB contents, no entries for "start_kernel" pages on I-TLB.
- "go".
- BDI stops at the end of start_kernel.
- dump I-TLB contents, see the 4kb entries for "start_kernel" I-cache
there (ie we _do_ get faults on these pages).
Check it out.
If your setup is not working yet I can get the data for you tomorrow.
> We need to create the
> page tables for informational purposes, so software or debugger
> lookups will do the right thing.
Can't the BDI work on the 8Mbyte page? Same for other software
or debuggers...
Any in-kernel algorithm which relies on direct pte manipulation
looks fragile...
i386 and some (?) other architectures do use big pages for the first
kernel addresses, right?
> >2) restricts bootmem to above 8Mbyte region
>
> Why is this necessary?
void __init
m8xx_setup_arch(void)
{
int cpm_page;
cpm_page = (int) alloc_bootmem_pages(PAGE_SIZE);
/* Reset the Communication Processor Module.
*/
m8xx_cpm_reset(cpm_page);
...
void
m8xx_cpm_reset(uint bootpage)
{
...
/* get the PTE for the bootpage */
if (!get_pteptr(&init_mm, bootpage, &pte))
panic("get_pteptr failed\n");
/* and make it uncachable */
pte_val(*pte) |= _PAGE_NO_CACHE;
_tlbie(bootpage);
host_buffer = bootpage;
host_end = host_buffer + PAGE_SIZE;
> >3) Memory for DMA pages must not be in the pinned region. ie. drivers
> >should not allocate memory directly for DMA purposes.
>
> Why not?
Because DMA pages need to have their PTE's marked as uncached, which in turn
means their TLB's need to be marked as uncached.
> It doesn't matter if we cover a VM space with a bunch of 4K
> entries or a single 8M entry. The physical pages are always going to
> be multiple mapped, either through the mapin_ram() space or a single 8M
> entry, and also through the vmalloc() space. You just have to ensure,
> in any case, that you don't access the pages through both VM spaces.
I dont think you can have multiple overlapping TLB entries.
How is the MMU supposed to decide between multiple mappings
for the same address ?
> >Dan, I would really enjoy having access to some of your precious 8xx
> >knowledge: share it, along with the correct way to fix this and the
> >other pending issues.
>
> The correct fix is rather simple, just make sure you configure the TLB
> to reserve entries, and get the pinned entries into those reserved
> entries.
That is how it is now. See previous posts with detailed TLB debugging.
> I know I had it right once, I don't know what happened :-)
Maybe you thought you got it right because the initial 8Mbyte
mapping works?
Unfortunately that mapping is trashed after overlapping
pte's are created.
> Just hang on and I'll get you some code to test ....
Sure...
next prev parent reply other threads:[~2005-05-07 0:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-05 17:20 [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries Marcelo Tosatti
2005-05-06 13:04 ` Jason McMullan
2005-05-06 11:39 ` Marcelo Tosatti
2005-05-06 16:43 ` Dan Malek
2005-05-06 13:38 ` Marcelo Tosatti
2005-05-06 22:49 ` Dan Malek
2005-05-06 20:03 ` Marcelo Tosatti [this message]
2005-05-07 3:09 ` Dan Malek
2005-05-06 23:05 ` Marcelo Tosatti
2005-05-07 4:39 ` Dan Malek
2005-05-07 5:16 ` Dan Malek
2005-05-07 13:16 ` Marcelo Tosatti
2005-05-07 20:02 ` Dan Malek
2005-05-07 15:47 ` Marcelo Tosatti
2005-05-07 14:05 ` Marcelo Tosatti
2005-05-09 6:09 ` Pantelis Antoniou
2005-05-07 14:59 ` Wolfgang Denk
2005-05-07 5:27 ` Dan Malek
2005-05-07 5:55 ` Dan Malek
2005-05-06 23:10 ` Dan Malek
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=20050506200338.GC14486@logos.cnet \
--to=marcelo.tosatti@cyclades$(echo .)com \
--cc=dan@embeddededge$(echo .)com \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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