Adding code to support Cache Management Operations
(CMO) defined by RV spec https://github.com/riscv/riscv-CMOs
Notes:
1. CMO only supports block based Operations. Meaning complete
cache flush/invd/clean Operations are not available
2. Current implementation uses ifence instructions but it
maybe platform specific. Many platforms may not support cache
Operations based on ifence.
3. For now adding CMO on top of ifence as it is not considered
harmful.
4. This requires support for GCC12.2 onwards.

Test:
1. Ensured correct instructions are refelecting in asm
2. Able to boot platform with RiscVVirtQemu config
3. Not able to verify actual instruction in HW as Qemu ignores
any actual cache operations.

Cc: Sunil V L <sunilvl@...>
Cc: Andrei Warkentin <andrei.warkentin@...>
Cc: Daniel Schaefer <git@...>
Signed-off-by: Dhaval Sharma <dhaval@...>
---
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c | 126 ++++++++++++++++=
++--
MdePkg/Library/BaseLib/RiscV64/RiscVCpuCache.S | 23 ++++
3 files changed, 143 insertions(+), 7 deletions(-)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/Ba=
seLib.inf
index 3a48492b1a01..0d6d6b7414c8 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -398,6 +398,7 @@ [Sources.RISCV64]
RiscV64/MemoryFence.S | GCC=0D
RiscV64/RiscVSetJumpLongJump.S | GCC=0D
RiscV64/RiscVCpuBreakpoint.S | GCC=0D
+ RiscV64/RiscVCpuCache.S | GCC=0D
RiscV64/RiscVCpuPause.S | GCC=0D
RiscV64/RiscVInterrupt.S | GCC=0D
RiscV64/FlushCache.S | GCC=0D
diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c b/MdePkg/L=
ibrary/BaseCacheMaintenanceLib/RiscVCache.c
index d08fb9f193ca..8e88b8391a74 100644
--- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
+++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
@@ -10,9 +10,111 @@
#include <Library/BaseLib.h>=0D
#include <Library/DebugLib.h>=0D
=0D
+/**=0D
+ Use runtime discovery mechanism in future when avalable=0D
+ through https://lists.riscv.org/g/tech-privileged/topic/83853282=0D
+**/=0D
+#define RV64_CACHE_BLOCK_SIZE 64=0D
+=0D
+typedef enum{=0D
+ cln,=0D
+ flsh,=0D
+ invd,=0D
+}CACHE_OP;=0D
+=0D
+/* Ideally we should do this through BaseLib.h by adding=0D
+ Asm*CacheLine functions. This can be done after Initial=0D
+ RV refactoring is complete. For now call functions directly=0D
+*/=0D
+VOID=0D
+EFIAPI RiscVCpuCacheFlush (=0D
+ UINTN=0D
+ );=0D
+=0D
+VOID=0D
+EFIAPI RiscVCpuCacheClean (=0D
+ UINTN=0D
+ );=0D
+=0D
+VOID=0D
+EFIAPI RiscVCpuCacheInval (=0D
+ UINTN=0D
+ );=0D
+=0D
+/**=0D
+ Performs required opeartion on cache lines in the cache coherency domain=
=0D
+ of the calling CPU. If Address is not aligned on a cache line boundary,=
=0D
+ then entire cache line containing Address is operated. If Address + Leng=
th=0D
+ is not aligned on a cache line boundary, then the entire cache line=0D
+ containing Address + Length -1 is operated.=0D
+=0D
+ If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().=0D
+=0D
+ @param Address The base address of the cache lines to=0D
+ invalidate. If the CPU is in a physical addressing mode,=
then=0D
+ Address is a physical address. If the CPU is in a virtua=
l=0D
+ addressing mode, then Address is a virtual address.=0D
+=0D
+ @param Length The number of bytes to invalidate from the instruction c=
ache.=0D
+=0D
+ @return Address.=0D
+=0D
+**/=0D
+=0D
+VOID *=0D
+EFIAPI=0D
+CacheOpCacheRange (=0D
+ IN VOID *Address,=0D
+ IN UINTN Length,=0D
+ IN CACHE_OP op=0D
+ )=0D
+{=0D
+ UINTN CacheLineSize;=0D
+ UINTN Start;=0D
+ UINTN End;=0D
+=0D
+ if (Length =3D=3D 0) {=0D
+ return Address;=0D
+ }=0D
+=0D
+ ASSERT ((Length - 1) <=3D (MAX_ADDRESS - (UINTN)Address));=0D
+=0D
+ //=0D
+ // Cache line size is 8 * Bits 15-08 of EBX returned from CPUID 01H=0D
+ //=0D
+ CacheLineSize =3D RV64_CACHE_BLOCK_SIZE;=0D
+=0D
+ Start =3D (UINTN)Address;=0D
+ //=0D
+ // Calculate the cache line alignment=0D
+ //=0D
+ End =3D (Start + Length + (CacheLineSize - 1)) & ~(CacheLineSize - 1)=
;=0D
+ Start &=3D ~((UINTN)CacheLineSize - 1);=0D
+=0D
+ do {=0D
+ switch (op) {=0D
+ case invd:=0D
+ RiscVCpuCacheInval(Start);=0D
+ break;=0D
+ case flsh:=0D
+ RiscVCpuCacheFlush(Start);=0D
+ break;=0D
+ case cln:=0D
+ RiscVCpuCacheClean(Start);=0D
+ break;=0D
+ default:=0D
+ DEBUG ((DEBUG_ERROR, "%a:RISC-V unsupported operation\n"));=0D
+ break;=0D
+ }=0D
+=0D
+ Start =3D Start + CacheLineSize;=0D
+ } while (Start !=3D End);=0D
+=0D
+ return Address;=0D
+}=0D
+=0D
/**=0D
RISC-V invalidate instruction cache.=0D
-=0D
**/=0D
VOID=0D
EFIAPI=0D
@@ -22,7 +124,6 @@ RiscVInvalidateInstCacheAsm (
=0D
/**=0D
RISC-V invalidate data cache.=0D
-=0D
**/=0D
VOID=0D
EFIAPI=0D
@@ -32,7 +133,9 @@ RiscVInvalidateDataCacheAsm (
=0D
/**=0D
Invalidates the entire instruction cache in cache coherency domain of th=
e=0D
- calling CPU.=0D
+ calling CPU. This may not clear $IC on all RV implementations.=0D
+ RV CMO only offers block operations as per spec. Entire cache invd will =
be=0D
+ platform dependent implementation.=0D
=0D
**/=0D
VOID=0D
@@ -77,11 +180,13 @@ InvalidateInstructionCacheRange (
)=0D
{=0D
DEBUG (=0D
- (DEBUG_WARN,=0D
+ (DEBUG_ERROR,=0D
"%a:RISC-V unsupported function.\n"=0D
"Invalidating the whole instruction cache instead.\n", __func__)=0D
);=0D
InvalidateInstructionCache ();=0D
+ //RV does not support $I specific operation.=0D
+ CacheOpCacheRange(Address, Length, invd);=0D
return Address;=0D
}=0D
=0D
@@ -93,6 +198,8 @@ InvalidateInstructionCacheRange (
of the calling CPU. This function guarantees that all dirty cache lines =
are=0D
written back to system memory, and also invalidates all the data cache l=
ines=0D
in the cache coherency domain of the calling CPU.=0D
+ RV CMO only offers block operations as per spec. Entire cache invd will =
be=0D
+ platform dependent implementation.=0D
=0D
**/=0D
VOID=0D
@@ -137,7 +244,7 @@ WriteBackInvalidateDataCacheRange (
IN UINTN Length=0D
)=0D
{=0D
- DEBUG ((DEBUG_ERROR, "%a:RISC-V unsupported function.\n", __func__));=0D
+ CacheOpCacheRange(Address, Length, flsh);=0D
return Address;=0D
}=0D
=0D
@@ -149,6 +256,8 @@ WriteBackInvalidateDataCacheRange (
CPU. This function guarantees that all dirty cache lines are written bac=
k to=0D
system memory. This function may also invalidate all the data cache line=
s in=0D
the cache coherency domain of the calling CPU.=0D
+ RV CMO only offers block operations as per spec. Entire cache invd will =
be=0D
+ platform dependent implementation.=0D
=0D
**/=0D
VOID=0D
@@ -192,7 +301,7 @@ WriteBackDataCacheRange (
IN UINTN Length=0D
)=0D
{=0D
- DEBUG ((DEBUG_ERROR, "%a:RISC-V unsupported function.\n", __func__));=0D
+ CacheOpCacheRange(Address, Length, cln);=0D
return Address;=0D
}=0D
=0D
@@ -205,6 +314,8 @@ WriteBackDataCacheRange (
written back to system memory. It is typically used for cache diagnostic=
s. If=0D
the CPU does not support invalidation of the entire data cache, then a w=
rite=0D
back and invalidate operation should be performed on the entire data cac=
he.=0D
+ RV CMO only offers block operations as per spec. Entire cache invd will =
be=0D
+ platform dependent implementation.=0D
=0D
**/=0D
VOID=0D
@@ -250,6 +361,7 @@ InvalidateDataCacheRange (
IN UINTN Length=0D
)=0D
{=0D
- DEBUG ((DEBUG_ERROR, "%a:RISC-V unsupported function.\n", __func__));=0D
+ //RV does not support $D specific operation.=0D
+ CacheOpCacheRange(Address, Length, invd);=0D
return Address;=0D
}=0D
diff --git a/MdePkg/Library/BaseLib/RiscV64/RiscVCpuCache.S b/MdePkg/Librar=
y/BaseLib/RiscV64/RiscVCpuCache.S
new file mode 100644
index 000000000000..0913ed3e9221
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/RiscVCpuCache.S
@@ -0,0 +1,23 @@
+//------------------------------------------------------------------------=
------=0D
+//=0D
+// CpuPause for RISC-V=0D
+//=0D
+// Copyright (c) 2022, Rivos Inc. All rights reserved.<BR>=0D
+//=0D
+// SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+//=0D
+//------------------------------------------------------------------------=
------=0D
+ASM_GLOBAL ASM_PFX(RiscVCpuCacheFlush)=0D
+ASM_PFX(RiscVCpuCacheFlush):=0D
+ cbo.flush (a0)=0D
+ ret=0D
+=0D
+ASM_GLOBAL ASM_PFX(RiscVCpuCacheClean)=0D
+ASM_PFX(RiscVCpuCacheClean):=0D
+ cbo.clean (a0)=0D
+ ret=0D
+=0D
+ASM_GLOBAL ASM_PFX(RiscVCpuCacheInval)=0D
+ASM_PFX(RiscVCpuCacheInval):=0D
+ cbo.inval (a0)=0D
+ ret=0D
--=20
2.40.0.rc0.57.g454dfcbddf

Hi Dhaval,

Thank you for looking at CMO support!

General comments first:
1) Please have a cover letter patch and move some part of the commit
message to cover letter. Please CC all maintainers in the cover letter
also.
2) Please run BaseTools/Scripts/GetMaintainer.py and CC all maintainers.
3) Follow
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

Have you run CI tests?

On Fri, Mar 24, 2023 at 09:13:41PM +0530, Dhaval Sharma wrote:

Adding code to support Cache Management Operations
(CMO) defined by RV spec https://github.com/riscv/riscv-CMOs
Notes:
1. CMO only supports block based Operations. Meaning complete
cache flush/invd/clean Operations are not available
2. Current implementation uses ifence instructions but it
maybe platform specific. Many platforms may not support cache
Operations based on ifence.

fence.i?

IMO, it is better to add a new library such as BaseRiscV64CMOLib and
included conditionally in the DSC for the platforms which support CMO.
BaseCacheMaintenanceLib will continue to have default fence.i
implementation. Is there an issue with this?

3. For now adding CMO on top of ifence as it is not considered
harmful.
4. This requires support for GCC12.2 onwards.

Yeah, this is another challenge like zifencei_zicsr which we could
workaround and support both older and newer tool chain. But for CMO,
I don't see any option but to support only GCC12.2+.

Thanks,
Sunil

On Mon, Mar 27, 2023 at 11:29:07PM +0530, Dhaval Sharma wrote:

My comments inline:

On Mon, Mar 27, 2023 at 9:12 PM Sunil V L <sunilvl@...> wrote:

Hi Dhaval,

Thank you for looking at CMO support!

General comments first:
1) Please have a cover letter patch and move some part of the commit

message to cover letter. Please CC all maintainers in the cover letter

also.

https://edk2.groups.io/g/devel/message/101795?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Ccmo%2C20%2C2%2C0%2C97826395.
Is this the one you are looking for?

Yes, sorry I missed it due to mail filters.

2) Please run BaseTools/Scripts/GetMaintainer.py and CC all maintainers.

Sure.

3) Follow

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

Have you run CI tests?

I actually did run it but I believe the current edk2 CI is using a GCC5
based compiler. Hence it failed as it did not recognize cmo instructions as
expected. So I submitted this as WIP patch to sort that out first.
Do let me know if I can follow any other better process here.

On Fri, Mar 24, 2023 at 09:13:41PM +0530, Dhaval Sharma wrote:

Adding code to support Cache Management Operations
(CMO) defined by RV spec https://github.com/riscv/riscv-CMOs
Notes:
1. CMO only supports block based Operations. Meaning complete
cache flush/invd/clean Operations are not available
2. Current implementation uses ifence instructions but it
maybe platform specific. Many platforms may not support cache
Operations based on ifence.

fence.i?

Ack.

IMO, it is better to add a new library such as BaseRiscV64CMOLib and
included conditionally in the DSC for the platforms which support CMO.
BaseCacheMaintenanceLib will continue to have default fence.i
implementation. Is there an issue with this?

There are 2 libraries involved here. 1. BaseCacheMaintenanceLib. It is a
generic Lib for multiple archs. So yes it is possible to create another
Lib, but I was thinking if it is possible somehow to create a RV specific
Lib.
2. BaseLib which contains required .S files. For CBO I have added a
separate .S. Again this is generic Baselib for all Arch. So we need to be
able to differentiate in DSC now for both these libs. I am not sure if this
is the
best way to address this. I could try to do inline assembly within
CMOCachelib to address #2.

I was thinking single independent library of CacheMaintenanceLib class
for CMO exclusively. Let BaseLib/BaseCacheMaintenanceLib continue to use
the default fence.i implementation. The DSC for the platform can chose
between default vs CMO libraries.

3. For now adding CMO on top of ifence as it is not considered
harmful.
4. This requires support for GCC12.2 onwards.

Yeah, this is another challenge like zifencei_zicsr which we could
workaround and support both older and newer tool chain. But for CMO,
I don't see any option but to support only GCC12.2+.

How do we support this in CI?

Oliver has a patch to update CI image to GCC12. I think it is not yet
merged. But I have not checked whether it is 12.2. You can run CI
including that patch with yours and try.

https://edk2.groups.io/g/devel/message/101164