From: Dan Malek <dan@embeddededge.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
Date: Sat, 7 May 2005 00:39:02 -0400 [thread overview]
Message-ID: <6f231f4afce0886929ca99426a86b47a@embeddededge.com> (raw)
In-Reply-To: <20050506230523.GA15908@logos.cnet>
On May 6, 2005, at 7:05 PM, Marcelo Tosatti wrote:
> Do you have any practical example which you are certain is going
> to break?
Not at the moment, but that doesn't mean we shouldn't maintain
consistency for anyone that wants to do so.
> I dont remember any, and I dont think any software should be walking
> kernel pte's directly...
Anyone can call get_pteptr and should get the proper information.
> It is not possible to have the 8Mbyte pinned TLB and 4kb pagetables
> mapping the same kernel virtual addresses.
I know, but we don't do that. Like I said, if the 8M pinned entry is
in the TLB, we don't get exceptions for this space and we don't look
up PTEs and replace them.
> You can't have both a 4kb page and a 8Mbyte page mapping the virtual
> address KERNELBASE + 0.
>
> Do you agree?
Yes, but that isn't what we are doing. We can have the 8M page
mapping virtual address 0xc0000000 to 0x0000000, and also another
4k page, at say 0xd0000000 map the same 0x00000000 physical page.
There are many circumstances when we have a kernel VM address
and a user VM address map the same physical page. This is also
what we do to get uncached VM addresses for DMA.
> Right - I'm talking about kernel virtual addresses: in this specific
> case,
> we can't have more than one mapping for the first page at KERNELBASE.
You can't do that in any case for anything, and I'm confused why you
keep mentioning this :-)
> So you do agree that pte's should not be created for the first
> 8MBytes if CONFIG_PIN_TLB is set? :)
NO. Just leave that code alone. I don't understand why you think
doing this will have any effect on the system operation. If you are
able to run a system without creating these tables, then the pinned
TLBs must be working. If pinned TLBs weren't working, the kernel
would crash.
Thanks.
-- Dan
next prev parent reply other threads:[~2005-05-07 4:39 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
2005-05-07 3:09 ` Dan Malek
2005-05-06 23:05 ` Marcelo Tosatti
2005-05-07 4:39 ` Dan Malek [this message]
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=6f231f4afce0886929ca99426a86b47a@embeddededge.com \
--to=dan@embeddededge.com \
--cc=linuxppc-embedded@ozlabs.org \
--cc=marcelo.tosatti@cyclades.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).