From: Bjorn Helgaas <bjorn_helgaas@hp.com>
To: parisc-linux@parisc-linux.org
Subject: [parisc-linux] parisc virtual aliasing
Date: Mon, 23 Apr 2001 14:26:55 -0600 [thread overview]
Message-ID: <01042314265503.26870@eeyore.fc.hp.com> (raw)
I'm going through the parisc code related to the issue of virtual
aliasing in the dcache and need a little insight into how things
currently work. Superdome deviates from the parisc architecture in
that non-equivalent aliasing (even for read-only pages, which the
architecture explicitly allows) causes HPMCs, so I'd like to tweak the
current support to make things work on Superdome.
In copy_user_page(), we currently do the copy using the permanent
kernel alias, then flush the destination from the dcache. The flush
will avoid a conflict between the kernel alias and the future user
mapping, but we may still have a conflict with a previous user mapping
unless there has been a flush before the copy. We could avoid the
conflict with a previous user mapping by either using an alias
equivalent to it (if we knew the old mapping) or flushing before the
copy.
In clear_user_page(), we currently purge the page from the dcache,
then clear it using a temporary alias equivalent to the eventual user
mapping. I think superdome lets you do flushes and purges using
arbitrary aliases, so the purge should avoid a conflict between a
previous user mapping and the temporary kernel mapping. The
equivalent alias should avoid any problem with the new user mapping.
We don't flush after clearing the page, so it seems like user attempts
to execute from the cleared page could read stale data from memory (on
all platforms, not just superdome).
So my questions:
- In copy_user_page(), has the destination page already been
flushed somewhere else? I think not, because I see virtual
index HPMCs there.
- Do we know the previous user mapping? If so, we could do
the copy using an equivalent alias to the previous mapping,
then flush once after the copy. If not, we may have to
flush before and after the copy.
- Are there any issues with the source of the copy? We flush
only the destination, so I'm assuming the source is some
kernel page that has no user aliases to worry about.
- In clear_user_page(), do we care whether user attempts to
execute from a cleared page get potentially stale data from
memory or zeros?
- Lastly, a question not specific to superdome:
flush_user_dcache_range() and flush_user_icache_range() either
flush just the requested range or the entire cache, depending
on the size of the range. Flushing just the range is done
with FDC, while flushing the entire cache is done with FDCE.
This seems like a problem for MP machines, because if you
flush a large enough range, the local cache will be flushed,
but remote ones will be untouched.
Bjorn
reply other threads:[~2001-04-23 20:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=01042314265503.26870@eeyore.fc.hp.com \
--to=bjorn_helgaas@hp.com \
--cc=parisc-linux@parisc-linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox