[libre-riscv-dev] system call (sc) LEV "reserved field"

[Luke Kenneth Casson Leighton]

On Thursday, July 23, 2020, Benjamin Herrenschmidt <benh at kernel.crashing.org>
wrote:

> On Thu, 2020-07-23 at 05:16 +0100, Luke Kenneth Casson Leighton wrote:
> >
> > what i have observed (again this is from RISCV), for instructions
> > that can be "safely ignored" are of a "hint" type.
>
> See what Paul said... the idea is that any change to an existing
> instruction that makes use of formerly reserved bits needs to be done
> in such a way that the ignoring the bits is a correct implementation.


this works well if extremely carefully managed, and planned well in advance.

at no time can the new functionality step *up* or otherwise be anything
other than an optimisation.

In practice that often means the new bits are indeed hints,


this is an accidental discovery!  i had not meant them to be considered
"hints" however now that you mention it, it makes a lot of sense.

lwsync would fall into this category.

 but not
> always, see Paul example about mfocrf.


indeed.  although it makes me nervous, that 2/2 cases quoted have known
issue where they did not go as planned.

i am guessing that mtmsr L=0/1 may also have been extended at some point?
that in an earlier version of the spec it was only L=0?



> > i.e. old sync is a "superset" of lwsync?
>
> sync is a memory barrier. lwsync is a lighter weight version of it, so
> yes, sync is a superset of lwsync.


ok, good.  so it is an optimisation.  as a "hint" type it would be "safe"

hints are only safe to add precisely because they are declared in advance -
long before anyone even implements the very first implementation of the
very first core - to have no change in functionality, merely an opportunity
for performance optimisation.


> > bit did not matter, the trap would call the alternative sync
> > instruction, and return from the trap.
>
> The performance impact of this would make it entirely unusable however.


in that example, yes.  most unfortunate.



>
> > i do not know the full story about what FSL is: without knowing the
> > details i suspect that a trap *could* have sorted things out, there,
> > *if* the older processor was required to raise "illegal instruction"
>
> FSL is Freescale.


ahh ok.


>
>

Some variants of their embedded cores did trap, which
> forced the kernel to do some nasty dynamic patching at runtime to get
> rid of lwsync's on these.


a low-grade version of JIT translation, which is one solution.  expensive,
but a solution.

although i have to ask why, for Embedded, they did not just recompile the
source code, customised for that enduser application.

however this also actually illustrates precisely why i mentioned that for
best results, a spec has to have different platform behaviour for Embedded
as completely separate and distinct from UNIX.

the rules for Embedded in RISCV state that traps are *not* needed for
illegal instructions (it is up to an implementor to decide if they wish to
add them).  the Conformance Test Suite does *not* test for illegal
instructions.

this on the basis that Embedded Markets are typically one-off deployment,
where the toolchain and all build source is "snapshotted" at product
release time, used internally and the source code and toolchain almost
never see the light of day.  mainline upgrades are exceptionally rare.

examples include Trinamic Stepper ASICs, which actually hit the shelves
even before RISCV Standardisation was ratified.

the binaries are in ROM.  whatever trap spec incompatibility with "Latest
and Greatest" are utterly irrelevant for them and their customers.


so in that context, i am slightly confused to hear that for Freescale
*Embedded* processors that there is even a binary incompatibility problem
with lwsync *at all*.

if you have time i'd love to hear more, what's the story there?




> > but because the bit is ignored, there is no way that can be done.
>
> But that's fine because "sync" is a strict superset so ignoring the bit
> works just fine.


in this case, yes.



>
> > so whilst on the face of it, lwsync *sounds* like a counterexample,
> > instead (caveat, i do not know what FSL is), it seems more to support
> > the case *for* use of reserved bits raising illegal instructions [on
> > UNIX platforms]
>
> I fail to follow your logic. The trap case is a complete non-starter
> for an instruction meant to be a lightweight memory barrier.


ok given that it is a "hint" type and not quite suited to "reserved" we are
now at cross purposes.

and, also, it is a special case that happens to gave, as one of its
requirements, to be "lightweight" in order to be useful.

The
> transparent "fallback" to a full memory barrier on the contrary works
> fine. There is never any case where "trapping an emulating" is the
> desired behaviour.


indeed... in this very special case that we have established, by it
effectively being a "hint", falls completely outside of what i am concerned
about


>
> >
> > > > if however reserved bits being set cause an exception, the "old"
> > > > processor stands a chance of emulating the new behaviour (in
> > > > software, even if that's slow), giving it a chance of keeping out
> > > of
> > > > landfill for slightly longer.
> > >
> > > Which is why powerpc tends not to "add bits" to instructions unless
> > > ignoring them is a safe fallback.
> >
> > as we can see above, the example that was given  shows that this is a
> > problematic approach.
>
> I fail to understand the "problem" in your example, maybe you can
> rephrase it ?


we've identified that lwsync is a "hint" so can discount it.

i'll need to take some more time to think about it.  also, it requires
explaining the context.

OpenPOWER is, under the auspices of the Foundation, i gather aiming for
much wider adoption whilst also retaining the reputation for performance
and stability, *and* allowing for extensions and customisation under the
stewardship of the Foundation.

with so few members using POWER up to this point, there has been little in
the way of conflict because there is no "pulling in different directions"
and, as Paul pointed out, a lot of care and thought has gone into any
upgrades.

looking for comparisons - examples from the past - is therefore actually
going to be difficult.


> > i have not spelled it out explicitly, seeking instead to use logical
> > reasoning rather than make categorical statements, but this is
> > actually a really serious problem.
>
> Again, experience seems to indicate this is not as long as the
> definition of the architecture is careful in how the reserved bits get
> allocated in the future.


if they are genuinely synonymous with (effectively) a "hint" then there is
absolutely no problem at all... *as long as* the entire area has been
declared fully and well in advance that it is of type "hint".

for example mtmsr L=1 (which i am assuming perhaps incorrectly was added
long after L=0, is that correct? if not let us assume hypothetically that
it was) absolutely in no way falls into the "safe" category because it
damages bits of MSR unexpectedly.  or only updates some of them.

in this (hypothetical?) case, modern software running on an older UNIX
Platform processor that only supported L=1 could *only* sort things out
*if* a trap was taken.

and yet the spec explicitly says, "don't bother", which is *guaranteed* to
cause problems.


SC having LEV > 1 in the future is also a special case because it is
*already* raising a trap.  no extra cost, there.  things can be sorted
out.... in the trap.



> > in other words the approach of ignoring reserved bits has only worked
> > (for the past 20 years?) because IBM, realistically, is the only
> > (non-Embedded) implementor of UNIX Platform processors.
>
> That wasn't always true and still didn't become a problem.
>
> Again, I really fail to see the smoking gun you seem to be implying
> there is.


no gun.

it is that things have changed, now.

where before the specification could be managed by a few vendors, for a few
vendors (managed extremely well) the intention as i understand it is to
expand the reach of OpenPOWER, and allow dozens if not hundreds of
implementors to participate in its ongoing evolution, just as is done with
RISCV.

under such changed circumstance it is well known and well established that
it is *not safe* to have reserved bits *not* throw exceptions on the UNIX
Platform.

bear in mind that we established that lwsync is a "hint", and that hints
*are* safe to add (as long as the available range is reserved fully, in
advance) and do not and should not raise exceptions because they are
performance optimisations.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68