masking of CSR bits/fields - transnational logic? will locking suffice?
On 2021-11-17 10:00 p.m., Vedvyas Shanbhogue wrote:
On Wed, Nov 17, 2021 at 05:02:12PM -0800, John Hauser wrote:This is the crux of the matter.Allen Baum wrote:Maybe a good definition of read-only would help since earlier you agreed to Allen but that text did not address the concept of read-only field holding on to written data instead of discarding the write. This behavior is quite unlike every other definition of read-only that I have come across.What follows is my interpretation of what I think is happening; it is notYes, you have it correct, Allen, although my text only addressed
Can the user understand what the out come will be? Does it match what the user wants it to be?
Not all of these examples are this situation, but the most difficult to understand what behaviour to expect occurs when there are transient invalid states.
The worst case is when a user wants an end state and there is no legal way [or at least non-distruptive during the transition steps] to get there.
We are thus in the realm of transactional logic.
It appears that this is what the output masking intends to provide.
The ideal would be BEGIN multiple update, check validity [read uncommitted], ROLLBACK or COMMIT.
Perhaps it would be instructional to consider this flexibility first.
Then look to see if LOCK (retain initial state), multiple update, check validity [read uncommitted], [reverse updates], UNLOCK is sufficient to provide management over the transition.
Certainly persistence of underlying state over extended operation [like alignment for transition out of and into C support] can be useful, but it can be emulated if software has transactional support.
Indeed with "transactional" support, it may be sufficient for software to read preliminary state and reestablish as needed.
The hardware designs obligations then are to not provide sufficient rope for the OS/VM/etc to hang itself.
Especially, not to activate any feature that the software is not prepared to support, that therefore the software does not explicitly enable.
An implementation may have a deterministic answer but if different implementations have different answer then software has to be prepared for each possible outcome.
I'm going to shortcut this discussion a bit to make sure we're not inventing new problems.
(for a very large definition of shortcut. This post isn't short....)
I've never seen a list of all the cases where there is a modifier bit that controls some other CSR field.
The obvious (to me) ones are:
clearing MISA bits turning off extensions; this generally removes CSRs entirely, it doesn't make them readonly.
setting SATP.mode which effects low order xTVEC bits (I think I have that right)
setting mseccfg bits may affect other CSRs, but in many cases those are write1-to-set, and the transactional nature is clear and deliberate.
This is clearly not a comprehensive list, but it would be good to see one for several reasons
The relevant one here is to avoid having us solve problems that don't exist.
I don't know how easy it is to extract this information from Sail, but riscv-config has a syntax to describe that, along with its illegal->legal syntax.
It doesn't necessarily comprehend new extensions yet.
So, before we go off on this tangent, we should understand the scope of this "problem"
Also, John said:
>> Compared to the first proposal, this one swings in the opposite direction toward maximal freedom for the implementation.
>> So how does everyone feel about this alternate proposal?
It was probably clear from my extensive screed, I'm not, which is ironic.
As a hardware architect, I love the idea of maximal freedom.
As chair of the arch-test SIG - not so much.
There is a distinction to me between
- an abstract freedom of implementation, and
- a speced freedom of implementation that causes code to produce different results.
I think that distinction has not been emphasized enough.
It doesn't just complicate my life as SIG chair, but software ecosystem and platform/profile definitions as well, and is an opening wedge into fragmentation.
And it often just isn't necessary.
There are explicit cases where it is (e.g. the results of memory accesses with and without fences)
where the spec is clear that if you want consistent results you must use fences, akak "if it hurts when you do that, don't do that"
That's an easy case; the reasoning and costs are clear (you could build a system that gave consistent results
and doesn't need fences, but HW or performance cost would be prohibitive)
In this CSR case: again, not so much.
If we are going to use "maximal freedom of implementation" as a reason for going down a particular path:
that decision must be justified with numbers, ideally, but a discussion of possible costs that restricting that freedom would cost.
In the CSR case: the costs are typically a handful of gates, and sometimes save logic.
If cases exist where this is not true: spec those CSR behaviors specifically. Otherwise, limit that freedom.
On Thu, Nov 18, 2021 at 8:40 AM Allen Baum <allen.baum@...> wrote:
I believe you are referring to mtvec.MODE (instead of satp.MODE) affecting the alignment requirements of mtvec.BASE. And same for stvec.
A few more off the top of my head:
Writing misa.H=0 makes many accessible bits into read-only 0.
mideleg masks sip, sie, hip, hie, and hideleg.
toggle quoted messageShow quoted text
Yes, mvtvec.MODE, not satp. Thanks. And thanks for the other examples.
I think all these examples are ones where that makes a field be read-only (and read-only zero).
Those are the easy ones really. I thought there were cases where legal values were restricted - but not to zero.
Embarrassingly, I can't come up with them off the top of my head, though
On Thu, Nov 18, 2021 at 9:57 AM Scott Johnson <scott.johnson@...> wrote:
On 2021-11-18 11:40 a.m., Allen Baum wrote:
There appears to be no shortage in desire for more tuning knobs and configuration settings.
We can add the hoops that RV32 split high/low of 64bit csr have
Not on mailing list. I didn't see this.
It was the latter of these is I intended to address.
I think the distinction is problematic in the comparison.
These are more than distinct manifestations of similar concepts.
They are different concepts altogether.
theoretical vs experimental.
abstract ideal vs tangible examples
If anyone has been conflating these then it is just awareness that is the problem
Yes a definite risk.
We should include errata concerns; and unexpected, perhaps impossible to diagnose, faillures.
agreed. But often isn't always.
We do need a feature that can guarantee 100% coverage. That is software can set any legal settings without race hazzards.
Problem is we already have allowed it.
And there is little political will to curtail.
Apparently we cannot don't admit we may have erred [even if just to one side or the other].
So I don't know all of what John wrote, so I do not know the full context of your response.
My main point was that we can view these sets of changes in a transactional manner, even those that are not clear and deliberate.
It provides another perspective for the analysis of any specific case, and the general use case.
LOCK could reasonably mean that during this csr setting sequence lower privilege code stalls on csr read or write.
It could also mean that while LOCKed csr values as seen off hart [interrupt controllers/ other harts] see the original and not the transient state.
The LOCKing level is able to see the transient state so it can validate that all is as intended before the UNLOCK which is effectively the commit.
If all is not as intended the software should reverse its changes [by rewriting the csr, validate they are OK, then UNLOCK.
If the software cannot reverse its changes it calls up to the next level for help until it eventually aborts/reboots.
Individual writes can still have a measure of Write Any Update to
but this could be further relaxed without compromising
establishing a Legal End Value
[nor complicating testing as this alternative is just write bits as written] readily verifiable for all bits that are architecturally writable]
In no way need this allow every bit in every csr to be writable.