Added pmm Support

[HAMZA-AFZAL404]

RISC-V Pointer Masking Extension Implementation

This PR features the implementation of the Pointer Masking Extension for the RISC-V architecture, enhancing the Base, Floating Point, Compressed, Vector and Atomics Instruction Set.

Changes

1. Implemented the mseccfg register with associated changes in riscv_sys_regs.sail ,riscv_insts_zicsr.sail ,riscv_sys_control.sail ,riscv_csr_map.sail

2. Updated the leglize_envcfg function and added functionsis_pmm_active ,legalize_mseccfg and get_pmm in riscv_sys_regs.sail.

3. Introduced functions transform_VA and transform_PA in riscv_insts_base.sail.

4. Implemented the function transform_effective_address. and Integrated transform_effective_address into the execution of LOAD and STORE functions of the targeted instruction files.

Testing

1. The functionality has been verified with several tests. However, testing is still ongoing. Once completed, the repository link will be shared promptly.

2. The self-checking tests have not been written yet. However, work has commenced on them and they should be available shortly.

[Timmmm]

Please can you link to the specification that this is intended to implement?

[martinmaas]

https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf

[jrtc27]

Putting pointer masking inside translateAddr would compose poorly with DDC on CHERI, which should authorise the actual masked virtual address used.

[arichardson]

We already have ext_data_get_addr which can be used for the CHERI DDC hooks and I presume should also apply in all these cases for pointer masking. I recall the virtual memory managemtn instructions are explicitly opted out in the spec for some reason, but that should be easier to handle than adding yet another hook.

[Timmmm]

Ah yeah we don't call translateAddr() for sfence.vma and friends so I think that should just work too.

You reminded me actually there's a bit of spec I didn't quite follow:

From an implementation perspective, ignoring bits is deeply connected to the maximum virtual and physical address space supported by the processor (e.g., Bare, Sv48, Sv57). In particular, applying the above transformation is cheap if it covers only bits that are not used by any supported address translation mode (as it is equivalent to switching off validity checks). Masking NVBITS beyond those bits is more expensive as it requires ignoring them in the TLB tag, and even more expensive if the masked bits extend into the VBITS portion of the address (as it requires performing the actual sign extension).

The Sail model has a TLB so maybe we need to do something, but I didn't quite get what it was trying to say here. It seems to be talking about 3 different cases:

1. it covers only bits that are not used by any supported address translation mode
2. it covers NVBITS beyond those bits
3. the masked bits extend into the VBITS portion of the address

It just doesn't seem to make any sense. There are only two parts of the address - NVBITS and VBITS, so what three cases is this referring to?

Can anyone say if we need to change the TLB code? I'm not sure.

[UmerShahidengr]

Regarding the comment on @jrtc27 and @Timmmm of implementing Pointer Masking in translateAddr(), I would say that pointer masking is different than virtual address translation, this implementation is efficient if not to be bounded inside translateAddr() function, it should be inside a different function (which is defined as transform_effective_address() here

[arichardson]

Regarding the comment on @jrtc27 and @Timmmm of implementing Pointer Masking in translateAddr(), I would say that pointer masking is different than virtual address translation, this implementation is efficient if not to be bounded inside translateAddr() function, it should be inside a different function (which is defined as transform_effective_address() here

IMO this should be part of ext_data_get_addr which already exists.