Date
1 - 13 of 13
xTVAL Compliance restriction proposal
When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says:
Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.
The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN. (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)
We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers. In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.
Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address. This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.
The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):
xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))
? sign_extend(address[VASIZE-1]
: ~sign_extend(address[VASIZE-1];
The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.
We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.
--> If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally, please select (reply with X following) "Yes."
--> If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses.
"No" responses without a sufficient explanation in the comments will not be considered.
Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)
No: ___ (our implementation is ISA compliant but doesn't conform to this constraint)
Comment (if you select "no" above):
andrew@...
On Sun, Jun 14, 2020 at 2:39 PM Allen Baum <allen.baum@...> wrote:
When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says:
Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.
The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN. (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)
We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers. In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.
Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address. This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.
The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):
xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))
? sign_extend(address[VASIZE-1]
: ~sign_extend(address[VASIZE-1];
The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.
We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.
--> If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally, please select (reply with X following) "Yes."
--> If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses.
"No" responses without a sufficient explanation in the comments will not be considered.
Yes: X (our implementation conforms to this constraint or implements XLEN bits)
No: ___ (our implementation is ISA compliant but doesn't conform to this constraint)Comment (if you select "no" above):
Greg Favor
Yes: X (our implementation conforms to this constraint or implements XLEN bits)
On Sun, Jun 14, 2020, 2:39 PM Allen Baum <allen.baum@...> wrote:
When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says:Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN. (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers. In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address. This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))? sign_extend(address[VASIZE-1]: ~sign_extend(address[VASIZE-1];The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.--> If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally, please select (reply with X following) "Yes."--> If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses."No" responses without a sufficient explanation in the comments will not be considered.Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)No: ___ (our implementation is ISA compliant but doesn't conform to this constraint)Comment (if you select "no" above):
Greg Favor
Allen,
How is compliance testing going to handle this issue for software (versus hardware) writes to *tval CSRs? For example, when software writes stval with an address, how is the validity judged? Is it based on S-mode and satp.MODE, or on the state of the current privilege and translation modes? Similarly, what happens when HS-mode writes vstval?
This is further ambiguity in the Priv spec that needs to be resolved - possibly (?) by you proposing a behavior that compliance will test for and thus require of any compliant implementations (and which the arch spec would then need to incorporate). I suspect there is no great answer; each has its own ugly points for software and/or for hardware.
Or should the specified behavior for software writes simply be that the written value is always treated as if valid, i.e store the low N bits in the storage flops and set the special N+1 flop as sign-extension of the low N bits? Or that hardware checks whether written bits [63:N] are sign-extension of
the low N bits? Both of these have their own uglinesses, and both would be wrong for Bare and M modes.
Greg
On Sun, Jun 14, 2020 at 2:39 PM Allen Baum <allen.baum@...> wrote:
When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says:Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN. (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers. In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address. This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))? sign_extend(address[VASIZE-1]: ~sign_extend(address[VASIZE-1];The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.--> If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally, please select (reply with X following) "Yes."--> If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses."No" responses without a sufficient explanation in the comments will not be considered.Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)No: ___ (our implementation is ISA compliant but doesn't conform to this constraint)Comment (if you select "no" above):
andrew@...
On Mon, Jun 15, 2020 at 10:40 PM Greg Favor <gfavor@...> wrote:
Allen,How is compliance testing going to handle this issue for software (versus hardware) writes to *tval CSRs? For example, when software writes stval with an address, how is the validity judged? Is it based on S-mode and satp.MODE, or on the state of the current privilege and translation modes? Similarly, what happens when HS-mode writes vstval?This is further ambiguity in the Priv spec that needs to be resolved - possibly (?) by you proposing a behavior that compliance will test for and thus require of any compliant implementations (and which the arch spec would then need to incorporate). I suspect there is no great answer; each has its own ugly points for software and/or for hardware.Or should the specified behavior for software writes simply be that the written value is always treated as if valid, i.e store the low N bits in the storage flops and set the special N+1 flop as sign-extension of the low N bits? Or that hardware checks whether written bits [63:N] are sign-extension of the low N bits? Both of these have their own uglinesses, and both would be wrong for Bare and M modes.
I focused on the HW writes to mtval when I described the Rocket core's behavior to Allen. The behavior for SW writes is that it unconditionally sign-extends from the most-significant implemented bit: in other words, the behavior that the MSBs are checked for a proper sign-extension only applies to HW writes. This is a reasonable implementation, and in some respects a preferable one. The purpose of the recoding is to provide information to SW. Enforcing the same constraints on SW writes is arbitrary, and might even be detrimental in some virtualization cases.
GregOn Sun, Jun 14, 2020 at 2:39 PM Allen Baum <allen.baum@...> wrote:When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says:Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN. (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers. In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address. This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))? sign_extend(address[VASIZE-1]: ~sign_extend(address[VASIZE-1];The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.--> If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally, please select (reply with X following) "Yes."--> If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses."No" responses without a sufficient explanation in the comments will not be considered.Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)No: ___ (our implementation is ISA compliant but doesn't conform to this constraint)Comment (if you select "no" above):
Greg Favor
On Mon, Jun 15, 2020 at 11:33 PM Andrew Waterman <andrew@...> wrote:
I focused on the HW writes to mtval when I described the Rocket core's behavior to Allen. The behavior for SW writes is that it unconditionally sign-extends from the most-significant implemented bit: in other words, the behavior that the MSBs are checked for a proper sign-extension only applies to HW writes. This is a reasonable implementation, and in some respects a preferable one. The purpose of the recoding is to provide information to SW. Enforcing the same constraints on SW writes is arbitrary, and might even be detrimental in some virtualization cases.
That sounds good.
It would be great to see this software write behavior added to the Priv spec (along with whatever hardware write behavior that Allen's polling concludes with).
Thanks,
Greg
andrew@...
On Tue, Jun 16, 2020 at 12:06 AM Greg Favor <gfavor@...> wrote:
On Mon, Jun 15, 2020 at 11:33 PM Andrew Waterman <andrew@...> wrote:I focused on the HW writes to mtval when I described the Rocket core's behavior to Allen. The behavior for SW writes is that it unconditionally sign-extends from the most-significant implemented bit: in other words, the behavior that the MSBs are checked for a proper sign-extension only applies to HW writes. This is a reasonable implementation, and in some respects a preferable one. The purpose of the recoding is to provide information to SW. Enforcing the same constraints on SW writes is arbitrary, and might even be detrimental in some virtualization cases.That sounds good.It would be great to see this software write behavior added to the Priv spec (along with whatever hardware write behavior that Allen's polling concludes with).
Thanks for your input, as always.
I agree that, if we ultimately agree to tighten the behavior here, we need to specify the behavior for both HW and SW writes.
Thanks,Greg
Greg Favor
Coming back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than PA size, the situation is a little more complicated when PA size is greater than VA size:
On hardware and software writes one wants to zero-extend if under M-mode or a Bare translation mode, or sign-extend if under a translated mode. In other words that one extra storage bit is loaded with either zero or sign extension of the highest supported address bit.
Compliance testing should keep this class of scenarios (i.e. PAsize > VAsize) in mind.
Greg
You said:
toggle quoted message
Show quoted text
Sign extend if translated
Zero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that)
Then you said that the extension would be from the highest address bit- but if VA>PA, isn’t that effectively zero extending the PA even in bare mode? That seems to contradict the first statement.
As usual, I’m probably interpreting something which might be interpreted more than one way in exactly the wrong way- that is my superpower. What am I getting wrong? Compliance wants to know!
-Allen
On Jun 30, 2020, at 12:45 PM, Greg Favor <gfavor@...> wrote:
Coming back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than PA size, the situation is a little more complicated when PA size is greater than VA size:On hardware and software writes one wants to zero-extend if under M-mode or a Bare translation mode, or sign-extend if under a translated mode. In other words that one extra storage bit is loaded with either zero or sign extension of the highest supported address bit.Compliance testing should keep this class of scenarios (i.e. PAsize > VAsize) in mind.Greg
andrew@...
The Rocket approach works here if you set the width of mtval to 1+max(VAbits,PAbits) and then sign-extend from the most-significant implemented bit. The extra 1 bit allows for zero-extension of PAs.
On Tue, Jun 30, 2020 at 6:19 PM Allen Baum <allen.baum@...> wrote:
You said:Sign extend if translatedZero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that)Then you said that the extension would be from the highest address bit- but if VA>PA, isn’t that effectively zero extending the PA even in bare mode? That seems to contradict the first statement.As usual, I’m probably interpreting something which might be interpreted more than one way in exactly the wrong way- that is my superpower. What am I getting wrong? Compliance wants to know!-AllenComing back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than PA size, the situation is a little more complicated when PA size is greater than VA size:On hardware and software writes one wants to zero-extend if under M-mode or a Bare translation mode, or sign-extend if under a translated mode. In other words that one extra storage bit is loaded with either zero or sign extension of the highest supported address bit.Compliance testing should keep this class of scenarios (i.e. PAsize > VAsize) in mind.Greg
Greg Favor
On Tue, Jun 30, 2020 at 4:19 PM Allen Baum <allen.baum@...> wrote:
You said:Sign extend if translatedZero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that)
One could view the effect of MPRV as changing the mode that is in effect for a memory access. For *tval purposes that end result is all that matters. Ditto for the new-ish HLV/HLVX/HSV instructions.
I don't think the new/added hypervisor VS/VU modes change much - since they are supposed to behave like S/U modes.
For two-stage translations what matters is the stage that is causing an exception and what that stage's translation mode is.
So I believe my admittedly terse statement is correct (albeit without all the extra verbiage describing these various cases). It is the relevant and final/effective privilege/translation modes that matter.
Then you said that the extension would be from the highest address bit- but if VA>PA, isn’t that effectively zero extending the PA even in bare mode? That seems to contradict the first statement.
I agree that if VA>PA, then always sign-extending from the implemented address msb works. My statement was addressing the case of PA>VA - in which sign-extending is not always correct.
Greg
As usual, I’m probably interpreting something which might be interpreted more than one way in exactly the wrong way- that is my superpower. What am I getting wrong? Compliance wants to know!-AllenComing back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than PA size, the situation is a little more complicated when PA size is greater than VA size:On hardware and software writes one wants to zero-extend if under M-mode or a Bare translation mode, or sign-extend if under a translated mode. In other words that one extra storage bit is loaded with either zero or sign extension of the highest supported address bit.Compliance testing should keep this class of scenarios (i.e. PAsize > VAsize) in mind.Greg
Greg Favor
Also a good implementation approach - adding a second variation to what WARL compliance testing would probably need to allow for.
At the end of the day, with both the "1-bit" and "2-bit" schemes, one is setting those 1-2 bits appropriately - based on the current modes and judging whether the 64-bit address being captured is "valid" or "invalid".
Greg
On Tue, Jun 30, 2020 at 4:29 PM Andrew Waterman <andrew@...> wrote:
The Rocket approach works here if you set the width of mtval to 1+max(VAbits,PAbits) and then sign-extend from the most-significant implemented bit. The extra 1 bit allows for zero-extension of PAs.On Tue, Jun 30, 2020 at 6:19 PM Allen Baum <allen.baum@...> wrote:You said:Sign extend if translatedZero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that)Then you said that the extension would be from the highest address bit- but if VA>PA, isn’t that effectively zero extending the PA even in bare mode? That seems to contradict the first statement.As usual, I’m probably interpreting something which might be interpreted more than one way in exactly the wrong way- that is my superpower. What am I getting wrong? Compliance wants to know!-AllenComing back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than PA size, the situation is a little more complicated when PA size is greater than VA size:On hardware and software writes one wants to zero-extend if under M-mode or a Bare translation mode, or sign-extend if under a translated mode. In other words that one extra storage bit is loaded with either zero or sign extension of the highest supported address bit.Compliance testing should keep this class of scenarios (i.e. PAsize > VAsize) in mind.Greg
Yes: X (our implementation conforms to this constraint or implements XLEN bits)
roger.
On Sun, Jun 14, 2020 at 11:39 PM Allen Baum <allen.baum@...> wrote:
When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says:Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN. (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers. In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address. This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))? sign_extend(address[VASIZE-1]: ~sign_extend(address[VASIZE-1];The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.--> If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally, please select (reply with X following) "Yes."--> If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses."No" responses without a sufficient explanation in the comments will not be considered.Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)No: ___ (our implementation is ISA compliant but doesn't conform to this constraint)Comment (if you select "no" above):