From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, linux@openrisc.net, jonas@southpole.se
Subject: Re: [PATCH 1/6] openrisc: add Kconfig for l.lwa and l.swa atomic instructions
Date: Thu, 24 Jul 2014 22:52:39 +0300 [thread overview]
Message-ID: <20140724195237.GA12313@chokladfabriken.org> (raw)
In-Reply-To: <20140723222601.51a8b788@alan.etchedpixels.co.uk>
On Wed, Jul 23, 2014 at 10:26:01PM +0100, One Thousand Gnomes wrote:
> > +config OPENRISC_HAVE_INST_LWA_SWA
> > + bool "Have instruction l.lwa and l.swa"
> > + help
> > + Select this if your implementation have l.lwa and l.swa atomic
> > + instructions.
> > +
> > endmenu
>
> Please do everyone a favour - sort all these out at runtime, add an
> architectural feature bits ROM address or catch the traps and use the
> alterntatives logic or something.
>
Detecting whether the instruction exists is of course trivial,
the hard part is what to do with this information at runtime.
My initial intention was to add emulation for the l.lwa and l.swa
instructions in the kernel, so a CPU without them would still
be able to run a kernel with CONFIG_OPENRISC_HAVE_INST_LWA_SWA enabled,
but inefficiently.
I will in either case add the kernel emulation,
since it's still needed to handle userspace occurences of these
instructions, perhaps that patch belong to this series as well.
I wasn't familiar with the alternatives logic before, so I had
to look it up.
Correct me if I'm wrong, but from what I gathered, the approach
that takes is especially suitable to fixup instructions that
are similar to each others but have slightly different properties
(the lock prefix to cmpxchg being the canonical example).
I guess it'd be *possible* to still use this method to implement
alternatives that would work in the UP case by disabling
context-switch and perform normal loads and stores in place
of the l.lwa and l.swa instructions, but is it really a good approach?
Stefan
next prev parent reply other threads:[~2014-07-24 19:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 21:18 [PATCH 0/6] openrisc: support " Stefan Kristiansson
2014-07-23 21:18 ` [PATCH 1/6] openrisc: add Kconfig " Stefan Kristiansson
2014-07-23 21:26 ` One Thousand Gnomes
2014-07-24 19:52 ` Stefan Kristiansson [this message]
2014-07-24 20:34 ` One Thousand Gnomes
2014-07-23 21:18 ` [PATCH 2/6] openrisc: add atomic bitops Stefan Kristiansson
2014-07-23 21:18 ` [PATCH 3/6] openrisc: add cmpxchg and xchg implementations Stefan Kristiansson
2014-07-23 21:18 ` [PATCH 4/6] openrisc: add atomic operations implementations Stefan Kristiansson
2014-07-23 21:18 ` [PATCH 5/6] openrisc: include l.swa in check for write data pagefault Stefan Kristiansson
2014-07-23 21:18 ` [PATCH 6/6] openrisc: add futex_atomic_* implementations Stefan Kristiansson
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=20140724195237.GA12313@chokladfabriken.org \
--to=stefan.kristiansson@saunalahti.fi \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jonas@southpole.se \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@openrisc.net \
/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
all inboxes | Powered by JetHome®