Conflicting exception types caused by misaligned AMO instructions. #1726
Comments
|
It seems clear to me: raise an access exception if the access shouldn't be emulated by M-mode software. |
which one misalign exception or access-fault exception is for unalign AMO? It isn't related to M mode |
|
How is an implementer to know what MMode software intends?
Should this
"not be emulated"
be clarified to be
"access exception" if the access was not permitted by a PMA, PMP or VM
permissions,
or page fault if a page fault is signalled and has higher priority than
misaligned
else misaligned". ?,
…On Thu, Nov 14, 2024 at 6:25 PM Andrew Waterman ***@***.***> wrote:
It seems clear to me: raise an access exception if the access shouldn't be
emulated by M-mode software.
—
Reply to this email directly, view it on GitHub
<#1726 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJTT5BT3XQKUY73NDDT2AVLSNAVCNFSM6AAAAABR2DYU76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZXHAZDKNJZHE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
How to understand the "emulated by M-mode software", Does it mean the expcetion would be handle by software run on M-mode? |
|
Yes. |
|
Hmm: the discussion we had is whether it should be
- emulated (by a higher privileged mode - could be delegated potentially),
signalled by a misaligned access exception cause, or
- be considered fatal and not be handled at all, by e.g. killing the
process, signalled by an illegal_access exception cause).
…On Thu, Nov 21, 2024 at 3:09 PM Andrew Waterman ***@***.***> wrote:
Yes.
—
Reply to this email directly, view it on GitHub
<#1726 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJVKNI52GXZWCCP7YO32BZR2PAVCNFSM6AAAAABR2DYU76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJSGUZTQMZRGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I was just answering a question about what we mean by "emulated by M-mode software". It is true that emulation by M-mode software is not the only possible outcome; misaligned accesses might result in visible traps in some environments. |
|
Yea, I was having trouble interpreting what he was asking, and what he
actually was understanding, so wanted to make sure there was no
ambiguities.
Otherwise, you're likely to get yet another question.
And here is another ambiguity: NMI is an interrupt.
Does it clear MIE? does it update MPIE? (like other interrupts)
Does it clear tcontrol MTE and MTPIE? (like other interrupts)
If an NMI occurs at the same time as some other trap or interrupt, which
takes priority? (it is unspecified, so could be either, correct?)
If it doesn't clear MIE or MTE, then the NMI handler could get
interrupted.; that sounds bad... (unless, in the trigger case, it goes to
debug mode;
it isn't clear if the triggered interrupt captures last instruction before
the NMI handler is entered, or after.
The MSB of mcause "should" be set - so that's an option (and you could
argue it isn't strictly necessary, since you jumped the NMI vector location)
The spec talks about how/when MTVAL gets updated on an
exception-by-exception basis, and says all other traps set it to zero.
But it only talks about which exceptions can set it, and does not mention
interrupts at all... e.g. NMI interrupts
I infer from the term "other traps" that it also includes interrupt traps.
Is that correct? So MTVAL is always written to zero (that is unspecified in
the spec
(we've been looking at the list of architectural options, and these and
others related to NMI are listed,
because we believe that Synposys/Imperas has customers that do it both
ways...
…On Thu, Nov 21, 2024 at 3:33 PM Andrew Waterman ***@***.***> wrote:
I was just answering a question about what we mean by "emulated by M-mode
software". It is true that emulation by M-mode software is not the only
possible outcome; misaligned accesses might result in visible traps in some
environments.
—
Reply to this email directly, view it on GitHub
<#1726 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJVTHRZX7M2DANM6O5D2BZUTDAVCNFSM6AAAAABR2DYU76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJSGU3DINRWHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In 《riscv-privlieged》，3.6.4. Misaligned Atomicity Granule PMA,It said
“If a misaligned AMO accesses a region that does not specify a misaligned atomicity granule PMA, or if not all accessed bytes lie within the same misaligned atomicity granule, then an exception is raised. For regular loads and stores that access such a region or for which not all accessed bytes lie within the same atomicity granule, then either an exception is raised, or the access proceeds but is not guaranteed to be atomic. Implementations may raise access-fault exceptions instead of address-misaligned exceptions for some misaligned accesses, indicating the instruction should not be emulated by a trap handler.”
Notice that:"Implementations may raise access-fault exceptions instead of address-misaligned exceptions for some misaligned accesses, indicating the instruction should not be emulated by a trap handler."
Need raise an acess-fault exceptions instead of address-misaligned exceptions
But in 《riscv-unprivileged》 14.4. "Zaamo" Extension for Atomic Memory Operations
For AMOs, the Zaamo extension requires that the address held in rs1 be naturally aligned to the size of the operand (i.e., eight-byte aligned for doublewords and four-byte aligned for words). If the address is not naturally aligned, an address-misaligned exception or an access-fault exception will be generated. The access-fault exception can be generated for a memory access that would otherwise be able to complete except for the misalignment, if the misaligned access should not be emulated.
Now we have a problem， which type exception should be raised when the address is not naturally aligned?
The text was updated successfully, but these errors were encountered: