Are there RISC-V core cache enable/flush operations?

[재민김]

Hi all,

As far as I have seen, the cache needs not be enabled, and cache is always enabled for any accesses

to the memory regieon that is predefined as cacheable (in MemAttr). Firstly am I correct about this?

Again, I don't think there is any cache flush instruction. Thus, I suppose that whenever memory sync is

required, RISC-V basically relies on fence/fence.i instructions. Is this also correct?

Or, are there some operations that similarly mimics cache flush operations that I haven't yet found?

Thanks in advance.

Jamie.

[Stefan O'Rear]

Correct, there is no standard cache flush instruction.
Implementations with incoherent memory (which is discouraged per
https://content.riscv.org/wp-content/uploads/2016/07/riscv-privileged-v1.9-1.pdf#page=49)
will need to implement a nonstandard instruction.

-s

[Richard Newell]

Incoherent cache content is not necessarily the only reason to flush the cache. This can be a tool to help prevent cache timing attacks.

Rich


G. Richard Newell
Senior Principal Product Architect, SoC Products Group, Microsemi Corporation
(408) 643-6146 (office), (408) 882-4785 (mobile), +1 (925) 478-7258 (Skype)
PGP: (2009 DSA-1024, ELG-4096) B751 FC13 8B4E 49DA 2270 35A2 20E4 E66A D0D0 2E34
(2016 SSA-4096, RSA-4096) 65F5 CCD6 23B3 BD3D CEDE AB58 171F F4DE E7D0 3ECA


-----Original Message-----
From: Stefan O'Rear [mailto:sor...@gmail.com]
Sent: Tuesday, October 25, 2016 8:08 AM
To: 재민김
Cc: RISC-V HW Dev
Subject: Re: [hw-dev] Are there RISC-V core cache enable/flush operations?

EXTERNAL EMAIL

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CADJ6UvO5esGbk3rpjPB4HzsMvX-jv4LNZQYR7b6uo7XVadBr3g%40mail.gmail.com.

[Michael Clark]

Cache flush can be used to construct cache timing attacks.

Control of caching domain and cache partitioning in multi-tenant environments can be used to mitigate cache timing attacks. Attacks can be made with or without cache flush (although it's harder without an explicit cache flush instruction) and the cache dimensions can be discovered via timing various access patterns.

Imagine there would be a construction that was somewhat like controlling a mask of several bits of the L3 cache key per hart. i.e. addr[k:j] & 0b111111 would have 64 domains sharing L3 cache. However it needs to be ternary versus binary to allow a subset of several harts to occupy 0b000000 and remove this cache key from the domain of other harts.

Michael

Sent from my iPhone

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/70CB6CF51F55FD4AAC2692F6A4068B18994D48E4%40sjsrvexchmbx2.microsemi.net.

[재민김]

Thank you all for the response.
I have further question.

I have tried changing the cacheability by changing the memory map configuratino in config scala file.
  => MemAttr(AddrMapProt.RWX, true / false)
It builds without any error, but regardless of using true of false, the address region seems to be accessed through the cache.

In both case, first access to every 64byte block takes a long time before it can
be fetched, but within the 64byte block, any later accesses are done in one cycle.
Again, when coming back to pre-executed 64byte block, all the fetches (including the first one) are done within a cycle.
I have also followed the signal to check that the instructions are fetched via the iCache unit.

So my questions is,
 1) Does the 'cacheable'/'non-cacheable' attribute work properly in the rocket chip? If not, when will it be fixed to work properly?
 2) If yes to 1, why are the instructions being cached regardless of the option I gave?
  - is it because the way I put in the option is wrong?
  - or, does the instruction cache ignores the cacheability attribute since they are read-only?

Anybody has any idea about this?

Jamie.

2016년 10월 26일 수요일 오전 4시 17분 3초 UTC+9, michaeljclark 님의 말:

[Andrew Waterman]

The instruction fetch stream is only coherent across a FENCE.I. In
this particular implementation, FENCE.I flushes the I$, so it is legal
for it to cache things marked uncacheable. In the future, we will
support truly uncached instruction fetch, but correct software should
function properly regardless.

> https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/63b6e419-9e83-4fa9-a2a5-c15224d29999%40groups.riscv.org.