Define behaviour for reserved RV32 permission encoding

[Timmmm]

The spec says

Valid capabilities must not have the permissions field set to a reserved value according to Table 3 when XLENMAX=32.

I believe this can't ever happen for tagged capabilities but CGetPerm works for non-tagged capabilities. What should it return for this? Same question for CAndPerm.

[andresag01]

Thanks for pointing this out. I agree that there is a gap in the spec regarding CGetPerm. However, CAndPerm does describe what happens in this case:

The AP field is not able to encode all combinations of permissions when XLENMAX=32. If
permissions that cannot be encoded are indicated, CANDPERM outputs a capability with
all architectural permissions cleared.

@PeterRugg had some comments about this behaviour, so there is a TODO note on it and should be picked up for discussion.

[PeterRugg]

Hmm, that's a good question, and links into how we define the reserved permission bits in a way that maximises compatibility in all cases. I imagine the interpretation of all the encoded permission bits could potentially change when the reserved bits are set by future or non-standard extensions, i.e. effectively interpreting some of them as format bits. That means software shouldn't rely on the interpretation of the existing bits if the reserved bits are set. It still needs to be defined, though, so maybe all zero?

[tariqkurd-repo]

I'm happy with all zeroes - as that doesn't exclude using the reserved value for a purpose other than representing permissions.

[Timmmm]

Ok that makes sense; I'll make a PR.