CSR per hart or per core?

[黃柏瑋]

Hi all,

I have a question about CSR when I read the code of Spike. 

Is CSR per hart or per core? In the priv spec, there isn’t a description about this.

Theses picture comes from spike/riscv/processor.c.

In the code, MISA is defined in processor, but MSTATUS is defined in hart.

I guess it should be per hart, and the spike just share some CSR across all harts.

Am I right? 

Moreover, why doesn’t the spec require CSR per hart? 

I will be appreciated for your help.

Po-wei

[Andrew Waterman]

The spec requires they be per-hart.  (The spec generally only talks about harts, and doesn't talk about cores, which are how the harts manifest in the microarchitecture.)

In Spike, the distinction is a bit fuzzy, because it doesn't support multi-threaded cores.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/A941C8ED-30CE-4921-89AB-B970A2F0F504%40gmail.com.

[John Leidel]

+1 to Andrew's note.  We had to do somewhat significant hacking to make Spike support multi-threaded cores for GC64. 

-- John D. Leidel 

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CA%2B%2B6G0B0OnC3dO%3DmhGJpTQ02MrQB72GZvN1kFfZRZBgcNboKbw%40mail.gmail.com.

[Vania Joloboff]

The privilege specs say (p22)

When a trap is taken from privilege mode y into privilege mode x, x
PIE is set to the value of y IE; x IE is set to 0; and x PP is set to y.

and then p28

By default, all traps at any privilege level are handled in machine
mode, though a machine-mode handler can redirect traps back to the
appropriate level with the MRET instruction (Section 3.2.1).
To increase performance, implementations can provide individual
read/write bits within medeleg
and mideleg to indicate that certain exceptions and interrupts
should be processed directly by a
lower privilege level.

I understand the phrase "when a trap is taken from privilege mode y into
privilege mode x",
to mean automatically, not using any MRET instruction. So if x is not
the M-mode,
it means there exists at least one delegation bit for that trap.

In other words a trap from y mode is taken into x mode if and only if
the corresponding bits
in the cascading delegation registers between M-mode and x mode are true
It is a necessary and sufficient condition.
Am I right ?

--
Best Regards,

Vania Joloboff
INRIA Bretagne Atlantique
Campus de Beaulieu
35042 Rennes Cedex
Tél: +33 (0)2 9984 7100
Fax: +33 (0)2 9984 7171

[Richard Herveille]

That's correct. I have been chewing on that for quite a while as well. 

You can check my implementation on GitHub; https://github.com/RoaLogic/RV12

Richard 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/c28e7ad9-0d77-0341-3180-37baf293d928%40inria.fr.

[Vania Joloboff]

Well, there is a problem.
It seems the delegation should not be allowed to delegate the trap
to a lower level of privilege than the initiating level.
I don't see this spelled out in the specs.
Am I missing a sentence somewhere ?

On 04/05/2017 05:45 PM, Richard Herveille wrote:
> That's correct. I have been chewing on that for quite a while as well.
> You can check my implementation on GitHub;
> https://github.com/RoaLogic/RV12
>
> Richard
>
> Sent from my iPhone
>
> On 5 Apr 2017, at 14:52, Vania Joloboff <vania.j...@inria.fr

>> <mailto:sw-dev+un...@groups.riscv.org>.

>> To post to this group, send email to sw-...@groups.riscv.org

>> <mailto:sw-...@groups.riscv.org>.

>> Visit this group at
>> https://groups.google.com/a/groups.riscv.org/group/sw-dev/

>> <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.

>> To view this discussion on the web visit
>> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/c28e7ad9-0d77-0341-3180-37baf293d928%40inria.fr.

[Stefan O'Rear]

On Thu, Apr 6, 2017 at 1:03 AM, Vania Joloboff <vania.j...@inria.fr> wrote:
> Well, there is a problem.
> It seems the delegation should not be allowed to delegate the trap
> to a lower level of privilege than the initiating level.
> I don't see this spelled out in the specs.
> Am I missing a sentence somewhere ?

https://github.com/riscv/riscv-isa-manual/blob/master/src/machine.tex#L1042-L1048

-s

[Richard Herveille]

Sure it does; that's exactly what delegation is. It is perfectly legal to delegate an M-mode(highest level) trap to U-mode (lowest level).
But I found this subject very confusing in the documentation as well.

Richard


Sent from my iPhone

> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/bed14d01-29e8-ce46-2d34-c6ec3d604d66%40inria.fr.