From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Dan Malek <dan@embeddededge.com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: map_page() and pinned TLB entries
Date: Thu, 16 Jun 2005 13:47:17 -0300 [thread overview]
Message-ID: <20050616164717.GA1915@logos.cnet> (raw)
In-Reply-To: <8efaee2824f500e906c2c05526ea3214@embeddededge.com>
On Thu, Jun 16, 2005 at 05:13:19PM -0400, Dan Malek wrote:
>
> On Jun 16, 2005, at 10:47 AM, Marcelo Tosatti wrote:
>
> >What would be an elegant way of dealing with this? We can insert
> >a conditional there such that only addresses not covered
> >by other mappings (in this case the 8Mbyte entry) get flushed.
>
> I'd like to make _tlbie() a macro on 8xx that simply tests the VA
> and doesn't invalidate anything in the pinned space. Of course,
> the code shouldn't be doing this anyway, and I think this
> should be treated as a bug if it happens.
Well it is expected that mapin_ram() flushes the va for the
PTE's being created.
That is the only well known occurence of _tlbie() on
a possibly pinned region.
I agree that adding a debugging check on _tlbie() to
catch invalidations in pinned space is a good thing.
> If the Linux VM thinks it needs to be doing this, pinned space
> isn't going to work.
Well the VM does that now, but it can be changed to skip the
pinned region.
>The _tlbie() is an exported symbol, I suspect for MOL, so
> we have to accommodate that.
What does MOL stand for?
> Thanks.
There are two separate approaches:
a) Fix mapin_ram() to skip pinned regions
b) Fix _tlbie() to skip pinned regions and warn about such
misusage.
If b) is chosen alone, which is what you seem to suggest, we
will get tons of warnings (or traps) anyway from mapin_ram().
So having that said, isnt the correct way out of this to change
both a) and b)?
next prev parent reply other threads:[~2005-06-16 21:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-16 14:47 map_page() and pinned TLB entries Marcelo Tosatti
2005-06-16 21:13 ` Dan Malek
2005-06-16 16:47 ` Marcelo Tosatti [this message]
2005-06-16 22:17 ` 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=20050616164717.GA1915@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=dan@embeddededge.com \
--cc=linuxppc-embedded@ozlabs.org \
/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.