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

[Benjamin Herrenschmidt]

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.

In practice that often means the new bits are indeed hints, but not
always, see Paul example about mfocrf.

> the RISCV Fence instructions also fell into this category.  being
> optimisations, less complex implementations could completely ignore
> them.
> 
> however in the example that you give - lwsync - i take it that this
> is a "less costly" cache/sync flush type instruction than the one
> that it was added to?
> 
> 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.

> this is very interesting to me, because i have made a longterm study
> of "how to develop stable specifications", and it is the first time
> in 25 years that i have encountered a counterexample to the practice
> of disallowing "reserved behaviour".
> 
> the "normal" way in "reserved is illegal" specifications, would be
> that lwsync would raise an illegal instruction on a processor that
> did not support it, the author of the trap would know that the extra
> 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.

> 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. 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. The cost of a trap is way too prohibitive
(and in some cases those could be use in code path that arent safe to
take traps in).

> 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.

> 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. 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.

> where of course this would become problematic is if lwsync (or other
> future added instruction) was part of a tight, performance-critical
> loop.  a trap and emulate in the middle of that would severely
> degrade older processor performance.  there is nothing that can be
> done about that.

Precisely.
> 
> > > 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 ?

 .../...

> sorry, Benjamin, i apologise for saying this: the question appears to
> be implying, very subtly, that you've not taken on board what i've
> said. if you had summarised what i wrote, in your own words, i would
> have a clear indicator that you'd heard me. if that is a
> misinterpretation i apologise.
> 
> the specific concern *is* that reserved bits do not cause illegal
> instructions to be raised on the UNIX Platform, because without that
> in place, UNIX platform longterm seamless upgradeability and
> interoperability between vendors across all their product ranges over
> time is simply not possible.

Experience with decades of POWER architecture however seems to
demonstrate the contrary. Again, we have yet to find a case where this
approach has be the source of a specific problem.

> 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.


> > IE. Actual examples where
> > this has been cause of breakage in the past ?
> 
> with PowerISA having only a few implementors, even though i am new to
> PowerISA i do not expect there to be many such examples, simply
> because as i said, for he "Embedded" class processors (Motorola's 32
> bit range, and even the Quorl 64 bit range can be said to be
> targetted at the "Embedded" market of Networking and Routing), these
> will not encounter this as a problem (because of the customised
> firmware that they run).
> 
> it is only the *UNIX* Platform where this matters.
> 
> that leaves, realistically, only the IBM POWER range.  and when there
> is only one vendor, interoperability with other vendors is not
> important when there aren't any other vendors!
> 
> however if PowerISA expands (as we know it would like to), and this
> is not changed, i *guarantee* that when more implementors are
> involved there will be problems, here.
> 
> 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.

Cheers,
Ben.