spec: Add XTheadMaee

[romanheros]

We name the mxstatus maee to a specific extension XTheadMaee, which describles whether enable the the extend page attributes in PTE or not.

[CLAassistant]

All committers have signed the CLA.

[cmuellner]

attributesin -> attributes in

[cmuellner]

We should probably clarify that XTheadMaee is a non-standard non-conforming extension.
The PTE bits that are used by MAEE are reserved for standard usage.
As far as I understood, this was caused by the fact that RVI did not have a standard yet and T-Head needed a solution.

[romanheros]

We should probably clarify that XTheadMaee is a non-standard non-conforming extension. The PTE bits that are used by MAEE are reserved for standard usage. As far as I understood, this was caused by the fact that RVI did not have a standard yet and T-Head needed a solution.
Yes, when c906 came to the world, RVI didn't have the standard with similar function. But now RVI has ratify the SVPBMT, which has the similar function with XTheadMaee. c908 supports both XTheadMaee and SVPBMT. And c907 and other newer CPUs only support SVPBMT.

[romanheros]

The XTheadMaee extension is not a custom-extension, but a non-standard non-conforming
extension. TheadMaee uses preserved [60:63] bits of PTE, which have been allocted to SVPBMT and SVNAPOT.
This conflict is not on purpose, but the result of issues in the past that have been resolved since. Therefore, the XTheadMaee extension and the SVPBMT or SVNAPOT extension are in conflict. In other words, tools should not allow to enable the TheadMaee extension and the SVPBMT or SVNAPOT at the same time and should report an error if both are enabled by the user.

[romanheros]

I think XTheadMaee is an custom extension, as it is controlled by an custom CSR. And actually, it can live with SVPBMT in the same hardware(such in C908). It just can't be enabled simultaneously with SVPBMT.

[cmuellner]

By definition, custom extensions can always be enabled with RVI extensions simultaneously. Also, the bits used by MAEE were marked as reserved in older RVI priv specifications that don't include Svpbmt. So, there is not much doubt that the XTheadMaee extension is non-conforming.

The issue was that PTEs don't have custom bits, and therefore, page attributes could not be set until Svpbmt was ratified (long after the C906 was in production).

But there is no point in reasoning why this happened and what could have been done differently since we are not here to blame someone for something, or to justify decisions that were made long ago. We just document technical details, so that others can understand the technical properties.

[cmuellner]

It is not defined (or referenced) what MXSTATUS is (it is a custom CSR with a certain number).
Also, we should probably give that CSR a prefix (e.g. TH_) like we do with instruction mnemonics to prevent name collisions with standard CSR names.

[romanheros]

OK. Yes, we can name it to TH_MXSTATUS. It's number is 0x7C0.

[cmuellner]

How can we find out if XTheadMaee is available on a system (how can the kernel find out if XTheadMaee is present or not).

[romanheros]

Usually it is the uboot spl or the zero stage boot, which run before the OpenSBI and the kernel, do the enable work by write 1 to TH_MXSTATUS MAEE field. Util now, the Linux kernel directly use the XTheadMaee. It doesn't detect. I think we should do it in the OpenSBI and export an interface to Linux kernel if we don't have a supervisor register.

[cmuellner]

Linux does not unconditionally write or read a bit in a custom CSR.
Instead, it needs to detect first that the kernel is running on a core that implements MAEE.
And that detection mechanism should be documented here (so the code can be reviewed against the specification).

[romanheros]

Yes, we can export the XTheadMaee through DTB. But util now, Linux can't read or write TH_MXSTATUS. It is not exposed in menvcfg like SVPBMT.

[romanheros]

If MVENDORID is 0x5B7, OS kernel should read TH_MXSTATUS MAEE as the enable status of XTheadMaee. Is this OK？

[cmuellner]

The current kernel implementation can be found here:

• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/kernel/alternative.c
• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/errata/thead/errata.c.

The following requirements are checked:

• static test: CONFIG_ERRATA_THEAD (riscv_fill_cpu_mfr_info)
• vendor_id == THEAD_VENDOR_ID (riscv_fill_cpu_mfr_info)
• static test: CONFIG_ERRATA_THEAD_PBMT (errata_probe_pbmt)
• arch_id == 0 (errata_probe_pbmt)
• impid == 0 (errata_probe_pbmt)

If I understand you correct, then you state that this is not sufficient and future proof.
You would also like to see a test for a set MAEE bit in TH_MXSTATUS (in errata_probe_pbmt).
This looks fine to me.

But now we have the question of the requirements for accessing TH_MXSTATUS.MAEE.
Is this CSR available for all cores with (vendor_id == THEAD_VENDOR_ID) && (arch_id == 0) && (impid == 0) (follow-up question: what about future cores?). If this test is sufficient, then we are done. If not, we need to clarify what is needed.

[romanheros]

This CSR available for all cores in Xuantie CPU. One shortcoming using TH_MXSTATUS.MAEE is that it can't be read from supervisor mode．If you don't think it is a problem, I am happy to add TH_MXSTATUS.MAEE as XTheadMaee proof. @cmuellner

[cmuellner]

I don't like so much the fact, that we introduce th.mxstatus here (I would prefer if we just introduce the MAEE bit). But I don't have a good proposal at the moment on how to structure this better. We could add another specification for th.mxstatus (and probably others) full of reserved bits and define only the MAEE bit here. This would clearly scale better, but since we only have one consumer specified yet, it is pointless at this time.

The important details (how to probe a CPU for the feature) are here, so let's keep it as it is for now.