[EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception. For example,
sw x11, 0(x7)
W width=4 bytes, so addresses A+0, A+1, A+2, and A+3 must all reside in a single PMP entry or an exception should be taken, regardless of what address A is.
Note, the spec does not say at this point whether the store(s) are allowed to succeed to memory.
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
Sent: Wednesday, January 12, 2022 2:54 PM
To: Greg Chadwick <gac@...>
Cc: Allen Baum <allen.baum@...>; Andrew Waterman <andrew@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
Well now we have three different interpretations!
FWIW, Spike implements misaligned accesses as I described.
On Wed, Jan 12, 2022 at 12:31 PM Greg Chadwick <gac@...> wrote:
My interpretation of this is if a misaligned store crosses between two PMP regions, both of which allow the write it's permissible for the implementation to allow both of those writes to occur, however you still get an illegal access fault (as all the bytes of the access didn't match a single PMP entry).
On Wed, Jan 12, 2022 at 8:02 PM Paul Donahue <pdonahue@...> wrote:
Interesting. I agree with Scott. It says "The matching PMP entry must match all bytes of an access" and "misaligned loads, stores, and instruction fetches may also be decomposed into multiple accesses." It's not that it must match all bytes that are accessed by a single instruction. It's that it must match all bytes of each access that gets performed by the implementation (not by a handler).
No matter who is correct, this obviously needs to be clarified.
Thanks,
-Paul
On Wed, Jan 12, 2022 at 11:48 AM Allen Baum <allen.baum@...> wrote:
I actually think that Oded has it right. IF the access fails because it crosses a PMP boundary - it's an illegal access fault.
The trap handler could decompose that into two separate transactions, each of which could succeed because neither crosses a boundary
- but those are no longer part of the original transaction.
A misaligned access could be broken up into two parts by the hardware as part of the original transaction without failing
- but only if the original request doesn't cross the boundary.
IF the transaction doesn't cross a boundary, but is broken up, then it is still possible that either of the broken up transactions may fail *for other reasons*
(e.g. crosses a page boundary with different access permissions).
In that case the first transaction will succeed, and the second could fail, and memory will be partially updated.
On Wed, Jan 12, 2022 at 11:15 AM Scott Johnson <scott.johnson@...> wrote:
I’m not sure I follow your response, Oded, but I believe the “decomposed” text in the spec exists specifically so that implementations may break up misaligned accesses. When they do so, it’s allowed that the two halves of the access map to different PMP entries. Both will succeed.
It’s also allowed to consider it as one access and take an exception because the PMP entry doesn’t match all bytes.
On Jan 12, 2022, at 7:04 AM, Oded Yishay <oded.yishay@...> wrote:
Please see the embedded reply below.
From: Ravinder Dasila <ravinder.dasila@...>
Sent: Wednesday, January 12, 2022 7:57 AM
To: tech-privileged@...
Cc: Sourav Roy <sourav.roy@...>; Jeff Scott <jeff.scott@...>; Oded Yishay <oded.yishay@...>
Subject: Query about PMP spec for misaligned access
Hello,
I’ve few queries regarding PMP spec for misaligned access.
As per the pmp section in privileged spec, there are two lines as follows:
- “The matching PMP entry must match all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
[<Oded>] “all bytes of an access” means the CPU access – (access_base_address + Access_Size - 1) must be in the same region as access_base_address or the access fails.
- “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed into multiple accesses, some of which may succeed before an access exception occurs.”
[<Oded>] “decomposed into multiple accesses”: these are the physical bus transactions.
Q. Does an ‘access’ for both these lines mean a ‘physical access’, or does the first one mean a ‘CPU access’ and the second one a ‘physical access’? [<Oded>] See above
Now, consider a scenario, where a misaligned store is done across 2 pmp regions and both the regions have write permission in pmpcfg csrs. In case:
- If a misaligned store is considered a single access, then as per point #1 above, it should generate an exception.
[<Oded>] If it meets the criteria – access_base_address AND (access_ base_address + Access_Size - 1) are in the same region – the access succeeds. Otherwise, it fails.
- However, if the misaligned store is considered as 2 separate physical accesses, then there should be no exception since we have to write permissions for both pmp regions and both accesses should be written to memory.
[<Oded>] Both bus transactions must be in the same region to succeed. Otherwise, the transaction fails (even if both bus transactions of the access succeed in different regions – it should fail – because the entire CPU access does not fail in the same region).
[<Oded>] I hope this clarifies the issue.
-Oded
Is our understanding correct here?
Regards,
Ravinder Dasila
<image002.png>
I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
Sent: Wednesday, January 12, 2022 5:14 PM
To: Greg Favor <gfavor@...>
Cc: Jeff Scott <jeff.scott@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
That is probably already the case even without PMP; the same thing might happen with just an MMU crossing page boundaries with 2 different permissions in each page.
There is a good case for allowing it, (to my chagrin) in that misaligned traps are supposed to be handled with simple byte by byte accesses.
I can't see a good use case to allow i though. My interpretation would shortcut that and not allow it (since the trap would have illegal op cause rrather than a misaligned cause)
I'm not sure if I can say if an implementation are any more or less complex, but I do see some added complexity,
On Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:
Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).
On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:
I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.
......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.
But let's see what Andrew says.
Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.
GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
On Wed, Jan 12, 2022 at 4:30 PM Greg Favor <gfavor@...> wrote:With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.Yeah, I was just writing something that I think is along these lines.If the misaligned access is decomposed into multiple pieces, each of which passes its PMP check individually, then the entire access might well succeed, even if the access, taken as a whole, spans PMP boundaries. But decomposing misaligned accesses is not required, and so trapping the access would also be permissible.
GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
On Wed, Jan 12, 2022 at 4:36 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:30 PM Greg Favor <gfavor@...> wrote:With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.Yeah, I was just writing something that I think is along these lines.If the misaligned access is decomposed into multiple pieces, each of which passes its PMP check individually, then the entire access might well succeed, even if the access, taken as a whole, spans PMP boundaries. But decomposing misaligned accesses is not required, and so trapping the access would also be permissible.And, as Greg was getting at, permitting the access to succeed in this case matches the software emulation story. If a misaligned access raises a misaligned trap and is emulated in software, byte by byte, then those accesses might all succeed despite the original access potentially crossing a PMP boundary.GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
From: Allen Baum <allen.baum@...>
Sent: Wednesday, January 12, 2022 5:14 PM
To: Greg Favor <gfavor@...>
Cc: Jeff Scott <jeff.scott@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
That is probably already the case even without PMP; the same thing might happen with just an MMU crossing page boundaries with 2 different permissions in each page.
There is a good case for allowing it, (to my chagrin) in that misaligned traps are supposed to be handled with simple byte by byte accesses.
I can't see a good use case to allow i though. My interpretation would shortcut that and not allow it (since the trap would have illegal op cause rrather than a misaligned cause)
I'm not sure if I can say if an implementation are any more or less complex, but I do see some added complexity,
On Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:
Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).
On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:
I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.
......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.
But let's see what Andrew says.
Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
I agree with this interpretation, but I have a concern about the spec. I think that the architecture document defines the interface between hardware and software. Hardware must take an access fault if a single access crosses PMP regions. Hardware has discretion over whether a single instruction is one access or multiple accesses. Software has no way of knowing how many accesses it is on any given implementation, except indirectly by seeing whether there's an access fault or not. At that point, isn't this saying "if it crosses PMP regions then it may fault" instead of "must fault"? The current spec is just telling software that it must fault if it faults which means nothing.
Thanks,-PaulOn Wed, Jan 12, 2022 at 4:37 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:36 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:30 PM Greg Favor <gfavor@...> wrote:With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.Yeah, I was just writing something that I think is along these lines.If the misaligned access is decomposed into multiple pieces, each of which passes its PMP check individually, then the entire access might well succeed, even if the access, taken as a whole, spans PMP boundaries. But decomposing misaligned accesses is not required, and so trapping the access would also be permissible.And, as Greg was getting at, permitting the access to succeed in this case matches the software emulation story. If a misaligned access raises a misaligned trap and is emulated in software, byte by byte, then those accesses might all succeed despite the original access potentially crossing a PMP boundary.GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
On Wed, Jan 12, 2022 at 4:42 PM Paul Donahue <pdonahue@...> wrote:I agree with this interpretation, but I have a concern about the spec. I think that the architecture document defines the interface between hardware and software. Hardware must take an access fault if a single access crosses PMP regions. Hardware has discretion over whether a single instruction is one access or multiple accesses. Software has no way of knowing how many accesses it is on any given implementation, except indirectly by seeing whether there's an access fault or not. At that point, isn't this saying "if it crosses PMP regions then it may fault" instead of "must fault"? The current spec is just telling software that it must fault if it faults which means nothing.It doesn't quite mean nothing, because there is also the case of naturally aligned accesses that span PMP boundaries: in particular, naturally aligned LD/SD on 4-byte PMP regions. Since naturally aligned accesses no wider than XLEN bits are required to be atomic, that isn't a "may fault" situation; it's a "must fault" situation. (With that said, I expect most implementers will design their way out of this situation by making the PMP granularity no finer than the widest supported access.)Ignoring that case, I agree that software must treat this as "may fault" in practice, but I don't think that fundamentally means the spec is problematic.Thanks,-PaulOn Wed, Jan 12, 2022 at 4:37 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:36 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:30 PM Greg Favor <gfavor@...> wrote:With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.Yeah, I was just writing something that I think is along these lines.If the misaligned access is decomposed into multiple pieces, each of which passes its PMP check individually, then the entire access might well succeed, even if the access, taken as a whole, spans PMP boundaries. But decomposing misaligned accesses is not required, and so trapping the access would also be permissible.And, as Greg was getting at, permitting the access to succeed in this case matches the software emulation story. If a misaligned access raises a misaligned trap and is emulated in software, byte by byte, then those accesses might all succeed despite the original access potentially crossing a PMP boundary.GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
Yeah, truth be told that case did cross my mind but I kind of glossed over that. There's obviously some confusion here so if it helps to say "may fault" (which would be a relaxation in that one case) or "must fault if it's a naturally aligned doubleword access that straddles a 4-byte PMP region and may fault otherwise" then I support either.Another case that I just thought of as I was typing: cbo.inval which straddles a PMP boundary that's even larger than 4 bytes. While cbo.zero is not atomic, cbo.inval presumably is (since you can't invalidate half a block). I really don't know how that is supposed to interplay with this PMP rule.
Thanks,-PaulOn Wed, Jan 12, 2022 at 4:57 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:42 PM Paul Donahue <pdonahue@...> wrote:I agree with this interpretation, but I have a concern about the spec. I think that the architecture document defines the interface between hardware and software. Hardware must take an access fault if a single access crosses PMP regions. Hardware has discretion over whether a single instruction is one access or multiple accesses. Software has no way of knowing how many accesses it is on any given implementation, except indirectly by seeing whether there's an access fault or not. At that point, isn't this saying "if it crosses PMP regions then it may fault" instead of "must fault"? The current spec is just telling software that it must fault if it faults which means nothing.It doesn't quite mean nothing, because there is also the case of naturally aligned accesses that span PMP boundaries: in particular, naturally aligned LD/SD on 4-byte PMP regions. Since naturally aligned accesses no wider than XLEN bits are required to be atomic, that isn't a "may fault" situation; it's a "must fault" situation. (With that said, I expect most implementers will design their way out of this situation by making the PMP granularity no finer than the widest supported access.)Ignoring that case, I agree that software must treat this as "may fault" in practice, but I don't think that fundamentally means the spec is problematic.Thanks,-PaulOn Wed, Jan 12, 2022 at 4:37 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:36 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:30 PM Greg Favor <gfavor@...> wrote:With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.Yeah, I was just writing something that I think is along these lines.If the misaligned access is decomposed into multiple pieces, each of which passes its PMP check individually, then the entire access might well succeed, even if the access, taken as a whole, spans PMP boundaries. But decomposing misaligned accesses is not required, and so trapping the access would also be permissible.And, as Greg was getting at, permitting the access to succeed in this case matches the software emulation story. If a misaligned access raises a misaligned trap and is emulated in software, byte by byte, then those accesses might all succeed despite the original access potentially crossing a PMP boundary.GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
On Wed, Jan 12, 2022 at 4:42 PM Paul Donahue <pdonahue@...> wrote:I agree with this interpretation, but I have a concern about the spec. I think that the architecture document defines the interface between hardware and software. Hardware must take an access fault if a single access crosses PMP regions. Hardware has discretion over whether a single instruction is one access or multiple accesses. Software has no way of knowing how many accesses it is on any given implementation, except indirectly by seeing whether there's an access fault or not. At that point, isn't this saying "if it crosses PMP regions then it may fault" instead of "must fault"? The current spec is just telling software that it must fault if it faults which means nothing.It doesn't quite mean nothing, because there is also the case of naturally aligned accesses that span PMP boundaries: in particular, naturally aligned LD/SD on 4-byte PMP regions. Since naturally aligned accesses no wider than XLEN bits are required to be atomic, that isn't a "may fault" situation; it's a "must fault" situation. (With that said, I expect most implementers will design their way out of this situation by making the PMP granularity no finer than the widest supported access.)Ignoring that case, I agree that software must treat this as "may fault" in practice, but I don't think that fundamentally means the spec is problematic.Thanks,-PaulOn Wed, Jan 12, 2022 at 4:37 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:36 PM Andrew Waterman <andrew@...> wrote:On Wed, Jan 12, 2022 at 4:30 PM Greg Favor <gfavor@...> wrote:With more thought, I'm reconsidering what I said - and now leaning to the alternative interpretation, i.e. that each physical access is checked. Whether emulation of a misaligned load/store instruction splits it into 2+ accesses, or hardware "splits" misaligned accesses (wrt some hardware-specific alignment boundary) into two separate parts (that are separately translated by the MMU and checked against PMP and PMA), these should both be architecturally allowed and not just one of the two allowed. Put differently, if the former is allowed architecturally, then the latter should be allowed as well. Software can't tell the difference between the two behaviors.Yeah, I was just writing something that I think is along these lines.If the misaligned access is decomposed into multiple pieces, each of which passes its PMP check individually, then the entire access might well succeed, even if the access, taken as a whole, spans PMP boundaries. But decomposing misaligned accesses is not required, and so trapping the access would also be permissible.And, as Greg was getting at, permitting the access to succeed in this case matches the software emulation story. If a misaligned access raises a misaligned trap and is emulated in software, byte by byte, then those accesses might all succeed despite the original access potentially crossing a PMP boundary.GregOn Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.But let's see what Andrew says.Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
If the processor does not support unaligned accesses, I agree. But, if the processor does support unaligned accesses, then my interpretation is you never take a misaligned fault.
Jeff
Sent: Wednesday, January 12, 2022 6:50 PM
To: Jeff Scott <jeff.scott@...>
Cc: Greg Favor <gfavor@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
That appears to be implementation defined (yet another option).
Table 3.7 of the priv spec says unaligned access can optionally have either higher or lower priority than access fault
On Wed, Jan 12, 2022 at 3:17 PM Jeff Scott <jeff.scott@...> wrote:
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
From: Allen Baum <allen.baum@...>
Sent: Wednesday, January 12, 2022 5:14 PM
To: Greg Favor <gfavor@...>
Cc: Jeff Scott <jeff.scott@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
That is probably already the case even without PMP; the same thing might happen with just an MMU crossing page boundaries with 2 different permissions in each page.
There is a good case for allowing it, (to my chagrin) in that misaligned traps are supposed to be handled with simple byte by byte accesses.
I can't see a good use case to allow i though. My interpretation would shortcut that and not allow it (since the trap would have illegal op cause rrather than a misaligned cause)
I'm not sure if I can say if an implementation are any more or less complex, but I do see some added complexity,
On Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:
Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).
On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:
I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.
......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.
But let's see what Andrew says.
Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
If the processor does not support unaligned accesses, I agree. But, if the processor does support unaligned accesses, then my interpretation is you never take a misaligned fault.
Jeff
From: Allen Baum <allen.baum@...>
Sent: Wednesday, January 12, 2022 6:50 PM
To: Jeff Scott <jeff.scott@...>
Cc: Greg Favor <gfavor@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
That appears to be implementation defined (yet another option).
Table 3.7 of the priv spec says unaligned access can optionally have either higher or lower priority than access fault
On Wed, Jan 12, 2022 at 3:17 PM Jeff Scott <jeff.scott@...> wrote:
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
From: Allen Baum <allen.baum@...>
Sent: Wednesday, January 12, 2022 5:14 PM
To: Greg Favor <gfavor@...>
Cc: Jeff Scott <jeff.scott@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
Caution: EXT Email
That is probably already the case even without PMP; the same thing might happen with just an MMU crossing page boundaries with 2 different permissions in each page.
There is a good case for allowing it, (to my chagrin) in that misaligned traps are supposed to be handled with simple byte by byte accesses.
I can't see a good use case to allow i though. My interpretation would shortcut that and not allow it (since the trap would have illegal op cause rrather than a misaligned cause)
I'm not sure if I can say if an implementation are any more or less complex, but I do see some added complexity,
On Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:
Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both regions permit their halves of the access).
On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:
I read this line in the spec : “The matching PMP entry must match
all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single instruction must reside in the same PMP entry or you should take an exception.
This is my understanding. And hence a PMP region straddling access must always fail.
......
Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
into multiple accesses, some of which may succeed before an access exception occurs. In particular,
a portion of a misaligned store that passes the PMP check may become visible, even if another
portion fails the PMP check.”
To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how it relates to the previous architecture statement.
I take this implementation statement to mean, if
sw x11, 0(x7)
was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
Is my interpretation correct?
That is my interpretation of the arch spec.
But let's see what Andrew says.
Greg
It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
Jeff
In terms of software compatibility and profiles, for U/S/HS modes -
which are not aware of PMPs - the discussion can be pushed to platform
level except via some platform-specific EEI, as the traps/emulation
happen in the outer EE. So, if PMP settings are made visible to the
<M-mode EE then a policy on straddling accesses has to be made as part
of that EEI.
For M-mode, there is no ambiguity, as all traps are visible, and this
is really the case for which the spec was written.
The specification does need some more clarification/restructuring, but
that will folded in to the general push to layer the privileged manual
more cleanly.
Related issues will show up if S-mode PMPs are added.
Krste
| I've been told by Andrew that this is not the case . Implementations may commonly handle unaligned accesses, until it can't, e.g. if it crosses a page boundary and thereOn Thu, 13 Jan 2022 10:11:43 -0800, "Allen Baum" <allen.baum@...> said:
| is no TLB entry for the second part of the fetch.
| Highly implementation dependent.
| Highly painful from a test perspective.
| On Thu, Jan 13, 2022 at 8:37 AM Jeff Scott <jeff.scott@...> wrote:
| If the processor does not support unaligned accesses, I agree. But, if the processor does support unaligned accesses, then my interpretation is you never take a
| misaligned fault.
|
| Jeff
|
| From: Allen Baum <allen.baum@...>
| Sent: Wednesday, January 12, 2022 6:50 PM
| To: Jeff Scott <jeff.scott@...>
| Cc: Greg Favor <gfavor@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <
| oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
| Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
|
| Caution: EXT Email
| That appears to be implementation defined (yet another option).
| Table 3.7 of the priv spec says unaligned access can optionally have either higher or lower priority than access fault
|
| On Wed, Jan 12, 2022 at 3:17 PM Jeff Scott <jeff.scott@...> wrote:
| Allen,
|
| My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
|
| Jeff
|
| From: Allen Baum <allen.baum@...>
| Sent: Wednesday, January 12, 2022 5:14 PM
| To: Greg Favor <gfavor@...>
| Cc: Jeff Scott <jeff.scott@...>; Andrew Waterman <andrew@...>; scott.johnson@...; Greg Chadwick <gac@...>; Oded Yishay <
| oded.yishay@...>; Paul Donahue <pdonahue@...>; tech-privileged@...
| Subject: Re: [EXT] Re: [RISC-V] [tech-privileged] Query about PMP spec for misaligned access
|
| Caution: EXT Email
| That is probably already the case even without PMP; the same thing might happen with just an MMU crossing page boundaries with 2 different permissions in each
| page.
| There is a good case for allowing it, (to my chagrin) in that misaligned traps are supposed to be handled with simple byte by byte accesses.
| I can't see a good use case to allow i though. My interpretation would shortcut that and not allow it (since the trap would have illegal op cause rrather than a
| misaligned cause)
| I'm not sure if I can say if an implementation are any more or less complex, but I do see some added complexity,
|
| On Wed, Jan 12, 2022 at 1:12 PM Greg Favor <gfavor@...> wrote:
| Cc'ing Andrew to provide a definitive answer on the Priv spec's intent as to whether an access that straddles two PMP regions must always fail (even if both
| regions permit their halves of the access).
|
| On Wed, Jan 12, 2022 at 12:58 PM Jeff Scott <jeff.scott@...> wrote:
| I read this line in the spec : “The matching PMP entry must match
| all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits.”
|
| as an architecture statement. Meaning : If you have single load or store instruction with width W to address A, all bytes covered by this single
| instruction must reside in the same PMP entry or you should take an exception.
|
| This is my understanding. And hence a PMP region straddling access must always fail.
|
| ......
| Now later in the spec it says “On some implementations, misaligned loads, stores, and instruction fetches may also be decomposed
| into multiple accesses, some of which may succeed before an access exception occurs. In particular,
| a portion of a misaligned store that passes the PMP check may become visible, even if another
| portion fails the PMP check.”
|
| To me, this is great information, but puzzling as well, because the font used is exactly the same as the previous architecture statement. I would expect
| this statement to be in italics like other parts of the spec that talk about implementation details. The fact that is not in italics makes me question how
| it relates to the previous architecture statement.
|
| I take this implementation statement to mean, if
| sw x11, 0(x7)
| was to a misaligned address, and broken up into two separate accesses by the implementation, if either access passes permission checks, it may very well
| succeed in updating memory, but you still must take an exception if all bytes of both accesses are not contained in one PMP entry.
|
| Is my interpretation correct?
|
| That is my interpretation of the arch spec.
|
| But let's see what Andrew says.
|
| Greg
|
| It is probably less logic to just consider each broken up access as a unique individual access and not take an exception if both accesses pass permissions
| individually, regardless of whether they are in separate PMP entries or not. If that is allowed, it is not clear to me from reading the spec.
|
| Jeff
|