Richard, again thanks for the review!
> This is a bit clumsy. I suggest
Sure, will fix.
> If you try to read this on current hardware, without J, then you get an exception not zero.
If I get the spec right, the idea is to read 0 from PM CSRs even if this extension is not present.
>I would have expected this check would actually go into the csr predicate function.
If I understand your proposal correctly, in this case I'd have to introduce 3 new functions for S/M/U PM CSRs as a predicate. I'm okay with that if you suggest so
>Surely you don't need MMTE_MASK here because you used it when writing.
>That said, don't you also need to mask vs the current priv level?
I suppose that applying these masks helps to prepare the correct value for the given priv level. So if I understand correctly if you're in M-mode and try to read UMTE, you'll get only U.Enable and U.Current, while if you'd try to read SMTE, you'll also get XS bits, S.Enable and S.Current.
> it's a security bug for lower priv code to read anything related to a higher priv.
Could you please elaborate a bit more here? I don't see how this scenario is valid: in U-mode you're supposed to be able to read only U* registers, while M/S mode could allow U-mode to write to its U* registers.
As for S-mode, I believe it's allowed to write to any U* registers and it's available to write to S* registers if S.Current is set.
> Do not crash qemu because the guest is doing silly things
Sure, you're right. Will fix.
>Raise an exception if you like, and perhaps qemu_log_mask with LOG_GUEST_ERROR
I think raising exception here might be too much, but logging the error is a great idea, thanks!
Thanks!