|
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
toggle quoted message
Show quoted text
From: tech-privileged@... <tech-privileged@...>
On Behalf Of Scott Johnson via lists.riscv.org
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.
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.
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.
Please see the embedded reply below.
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.
Is our understanding correct here?
|
|
|
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).
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 Baum
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).
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
toggle quoted message
Show quoted text
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).
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.
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.
Greg
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).
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.
Greg 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).
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.
Greg 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).
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,
-Paul
On 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.
Greg 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).
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 Baum
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
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
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).
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.
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.
On 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.
Greg 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).
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,
-Paul
On 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.
On 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.
Greg 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).
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 5:14 PM Paul Donahue < pdonahue@...> wrote: 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.
The CMO spec suggests the outcome is unspecified. In practice, I suspect this is another case that will be made moot by coarsening the PMP granularity so the situation cannot arise.
On 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.
On 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.
Greg 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).
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 Baum
IF there is a rare corner case that changes "may" to "must" (and vice-versa!), then I think (no surprise) the spec should have non-normative text to point that out. It helps designers, it helps DV, it helps ACTs (self serving, yes), it may help software and firmware. It would be better if they didn't have to discover it the hard way. The fact that no one else came up with that corner case is indicative of the need for that. Some clarification that the condition applies to the actual bus transaction(s) - and not what the instruction encoding indicates - is the other obvious bit of text that is needed, and probably normative to make it very, very obvious,
I'm not sure I'd agree that the spec isn't problematic; the spec isn't wrong, but the fact that people were arguing about this and had to go to you is my definition of problematic.
On 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.
On 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.
Greg 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).
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
toggle quoted message
Show quoted text
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
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
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).
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.
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 Baum
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 there is no TLB entry for the second part of the fetch. Highly implementation dependent. Highly painful from a test perspective.
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
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
Allen,
My assumption is the cause would be load or store access fault if all bytes are not in one PMP region.
Jeff
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).
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.
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
|
|
|
Krste Asanovic
The current PMP checks isolate M mode from lower-privilege modes. 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 On Thu, 13 Jan 2022 10:11:43 -0800, "Allen Baum" <allen.baum@...> said:
| 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 there | 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 |
|
|
|
