Do hart IDs (mhartid values) have to be unique?

52 views
Skip to first unread message

Tomislav Petricevic

unread,
Aug 31, 2018, 9:28:58 AM8/31/18
to isa...@groups.riscv.org
Hi everyone,

as a "hardware noob" let me first thank everyone in the RISC-V community
for their contributions to such an awesome project.

I have a (possibly stupid) question regarding which hart IDs are legal
in a system.

V1.10 of the privileged ISA specification states:

> The mhartid CSR is an XLEN-bit read-only register
> containing the integer ID of the hardware thread running
> the code. This register must be readable in any
> implementation. Hart IDs might not necessarily be numbered
> contiguously in a multiprocessor system, but **at least one
> hart** must have a hart ID of zero.

The comment below says:

> In certain cases, we must ensure **exactly one hart** runs
> some code (e.g., at reset), and so require one hart to have
> a known hart ID of zero.

That seems to imply that, even in a multiprocessor system with swappable
multicore processors (e.g., the usual rack server with multiple CPU
sockets), there has to be exactly one hart with an ID of zero. If this
is the intended case (as I think) it might be useful to add the term
"unique" to the first paragraph quoted:

> [...] but at least one hart must have a **unique** hart ID
> of zero.

That way it is made clear that "but at least" refers to "might not
necessarily be numbered contiguously in a multiprocessor system" and
must not be understood as "there is a possibility of more than one hart
having an ID of zero."

I guess that would make it the CPU/platform vendor's responsibility to
provide some kind of arbitration mechanism to fill in the mhartid
register values across all the processors present in the system? Or am I
totally wrong with my assumptions and hart IDs may in fact refer to
multiple harts in the system?

Kind regards,
Tomislav Petricevic

Allen Baum

unread,
Aug 31, 2018, 2:03:59 PM8/31/18
to tomi...@petricevic.me.uk, RISC-V ISA Dev
My reading of the spec is that yes, you need a unique hartID 0.

From a software point of view: you need a way to identify a hart uniquely, primariy to send SW interrupts.
There are other ways to identify things (e.g. processID), but underneath it all is mapping to its hartID, and for that you can't have more than one hart for a hartID.
This does not preclude SW (or HW)  from having a way to effectively substitute hartID 0 (e.g when you need to swap out a core), either by having a way to change the ID of the guaranteed-to-be-present hart, or by ensuring that SW knows that it should use some other hartID instead of 0, but but at reaset, you are required to have a single hart to have hartID 0.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/deba244e-a5dd-a1cf-4dc5-a46fbbaf9997%40petricevic.me.uk.

Andrew Waterman

unread,
Aug 31, 2018, 2:41:04 PM8/31/18
to Allen Baum, tomi...@petricevic.me.uk, RISC-V ISA Dev
Hart IDs should be unique.  The early boot process might have to take some action to make this the case (e.g., multi-socket systems might dynamically negotiate their socket IDs, thereby influencing their harts' IDs), but by the time standard software starts running, the hart IDs should be unique.

Tomislav Petricevic

unread,
Sep 1, 2018, 9:36:47 AM9/1/18
to isa...@groups.riscv.org, allen...@esperantotech.com, wate...@eecs.berkeley.edu

That makes sense.

@Andrew: where would you put the boundary between standard and non-standard software in this context? I guess bbl would be considered standard, while prior boot stages may not necessarily have that luxury?

Andrew Waterman

unread,
Sep 1, 2018, 1:24:03 PM9/1/18
to Tomislav Petricevic, allen...@esperantotech.com, isa...@groups.riscv.org
I can’t demarcate standard and nonstandard software without a clear definition of an execution environment, but to quote Potter Stewart, “I know it when I see it.” bbl is a low-level chain loader, but it is meant to run on a few different platforms, so it’s de-facto standard. It would fail to execute correctly if hart IDs weren’t unique.

I’ll make sure to update the spec to reflect this conversation.

On Sat, Sep 1, 2018 at 6:36 AM Tomislav Petricevic <tomi...@petricevic.me.uk> wrote:

That makes sense.

@Andrew: where would you put the boundary between standard and non-standard software in this context? I guess bbl would be considered standard, while prior boot stages may not necessarily have that luxury?

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

Tomislav Petricevic

unread,
Sep 1, 2018, 2:23:59 PM9/1/18
to Andrew Waterman, allen...@esperantotech.com, isa...@groups.riscv.org
Okay, thank you both for your quick replies!
Reply all
Reply to author
Forward
0 new messages