Date
1 - 12 of 12
Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure
Greg Favor
The new "unified RISC-V low-level discovery method" being developed by tech-config (for use by all extensions that have information that needs to be easily discoverable by software), is almost completely software-based. The compressed binary config structure (containing all the discovery information) will reside somewhere in system physical address space and will be read and decoded (based on a standardized RISC-V schema) by an M-mode parser/decoder into all the individual discoverable items available for use by software.
Typically M-mode software, during the boot flow, may make use of some of this information, but much of that information will be populated into a high-level discovery structure for use by other software components in the system (e.g. Device Tree or ACPI tables in Linux-class systems; Device Tree or some other suitable structure in embedded systems). Other agents, such as an external debugger, may also read and parse this structure for discovering Debug and Trace architecture related information.
To support this, each hart needs to have a CSR that provides an address pointer to the memory-resident config data structure - which can reside anywhere in system address space and may physically reside on or off chip in whatever suitable form of storage. This fast track extension standardizes this CSR. This email (I'm helping out the people developing the overall discovery method) starts a prelim review of this extension on the tech-priv and tech-config email lists.
The proposed official extension name is 'Smdisc'.
The 'mconfigptr' CSR is an MXLEN-wide R/W M-mode CSR that provides a system physical address pointer to a memory-resident config data structure to be used by a software method for low-level discovery of configuration information about harts and the rest of the system. Some implementations may hardwire this CSR to a suitable value. The assigned CSR number is 0x750.
Greg
P.S. The Debug Architecture already contains config structure pointer registers in the Debug Module for use by an external debugger.
so how do we communicate this to the world?
csr is an ISA extension
config tab is a software only Non-ISA doc rule required only by a platform spec?
So could you do discovery in some other way and be profile compatible but not platform compatible?
or since this is a hybrid spec with ISA and non-ISA and gets ratified together it is different? (btw The new regs already cover this kind of doc). Would we want the policy to say that extensions ratified in a hybrid spec require the implementer to implement both ISA and non-ISA to claim RISC-V compatible?
I am the first one in favor of separation of ISA and non-ISA but I must admit this one makes me feel uncomfortable in just saying it is just SW and allow the possibility of variations both being RISC-V (profile) compatible.
or am I misunderstanding?
Mark
On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...> wrote:
The new "unified RISC-V low-level discovery method" being developed by tech-config (for use by all extensions that have information that needs to be easily discoverable by software), is almost completely software-based. The compressed binary config structure (containing all the discovery information) will reside somewhere in system physical address space and will be read and decoded (based on a standardized RISC-V schema) by an M-mode parser/decoder into all the individual discoverable items available for use by software.Typically M-mode software, during the boot flow, may make use of some of this information, but much of that information will be populated into a high-level discovery structure for use by other software components in the system (e.g. Device Tree or ACPI tables in Linux-class systems; Device Tree or some other suitable structure in embedded systems). Other agents, such as an external debugger, may also read and parse this structure for discovering Debug and Trace architecture related information.To support this, each hart needs to have a CSR that provides an address pointer to the memory-resident config data structure - which can reside anywhere in system address space and may physically reside on or off chip in whatever suitable form of storage. This fast track extension standardizes this CSR. This email (I'm helping out the people developing the overall discovery method) starts a prelim review of this extension on the tech-priv and tech-config email lists.The proposed official extension name is 'Smdisc'.The 'mconfigptr' CSR is an MXLEN-wide R/W M-mode CSR that provides a system physical address pointer to a memory-resident config data structure to be used by a software method for low-level discovery of configuration information about harts and the rest of the system. Some implementations may hardwire this CSR to a suitable value. The assigned CSR number is 0x750.GregP.S. The Debug Architecture already contains config structure pointer registers in the Debug Module for use by an external debugger.
Greg Favor
On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...>
"Some implementations may hardwire this CSR to a suitable value."
This should have been better worded as:
"Upon reset this CSR is initialized to a suitable pointer value. Some implementations may only provide read-only CSR access to this value. This value may actually be hardwired, or may be writeable or controllable only through implementation-specific means."
Greg
Tim Newsome <tim@...>
On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...> wrote:
The 'mconfigptr' CSR is an MXLEN-wide R/W M-mode CSR that provides a system physical address pointer to a memory-resident config data structure to be used by a software method for low-level discovery of configuration information about harts and the rest of the system. Some implementations may hardwire this CSR to a suitable value. The assigned CSR number is 0x750.
Why is the CSR writable? What's the use case for that? (Hypervisor writing it for an M mode system underneath? But then it's still not writable in M mode.)
Tim
Greg Favor
On Mon, Jun 28, 2021 at 12:47 PM Mark Himelstein <markhimelstein@...> wrote:
csr is an ISA extensionconfig tab is a software only Non-ISA doc rule required only by a platform spec?
Yes on both counts.
So could you do discovery in some other way and be profile compatible but not platform compatible?
Profile specs (or at least A profile specs) would require this ISA extension. Platforms would require, if they so choose, use of the RISC-V standard software low-level discovery method as well.
or since this is a hybrid spec with ISA and non-ISA and gets ratified together it is different? (btw The new regs already cover this kind of doc).
In this case this all doesn't need to be viewed as a single hybrid spec. The ISA extension provides a generic standard mechanism for pointing to a memory-resident discovery structure. The RISC-V standard software low-level discovery method will require support for this ISA extension and will make use of this CSR.
But the two can be treated and ratified separately (whether concurrently or sequentially). This is just like the Debug Arch spec specifying config pointer registers without talking about any particular discovery method.
Greg
Tim Newsome <tim@...>
One addition:
If the CSR contains 0, software should assume there is no configuration structure.
I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.
Tim
On Mon, Jun 28, 2021 at 1:02 PM Tim Newsome <tim@...> wrote:
On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...> wrote:The 'mconfigptr' CSR is an MXLEN-wide R/W M-mode CSR that provides a system physical address pointer to a memory-resident config data structure to be used by a software method for low-level discovery of configuration information about harts and the rest of the system. Some implementations may hardwire this CSR to a suitable value. The assigned CSR number is 0x750.Why is the CSR writable? What's the use case for that? (Hypervisor writing it for an M mode system underneath? But then it's still not writable in M mode.)Tim
Greg Favor
On Mon, Jun 28, 2021 at 1:02 PM Tim Newsome <tim@...> wrote:
Why is the CSR writable? What's the use case for that? (Hypervisor writing it for an M mode system underneath? But then it's still not writable in M mode.)
Many systems will have this CSR as only readable (along the lines of my earlier P.S.). But flexibility is allowed for possible use cases where the pointer wants to be changeable by M-mode to point to another memory-resident config structure.
Pulling a theoretical possibility out of the air - which is a form of bootstrapping scenario: Maybe a tiny config structure in a small on-chip or off-chip ROM/PROM is read to find out some key initial system characteristics - including where to find the full-blown structure. And maybe that structure first needs to be read into memory from an off-chip SPI flash device. (Maybe both the full config structure and the associated decoder/parser code blob need to be read in.)
Or maybe this is a single-stage scenario where the config structure and code blob need to be read in from SPI flash by the early implementation-specific boot flow and placed in memory - and mconfigptr then set to point to the config structure.
The point is to allow flexibility and not foreclose useful scenarios that we may not readily imagine or expect at this moment.
Greg
Greg Favor
On Mon, Jun 28, 2021 at 1:29 PM Tim Newsome <tim@...> wrote:
One addition:If the CSR contains 0, software should assume there is no configuration structure.
Agreed.
I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.
That's OK. The extension would then define the low two bits as "00" and as "Reserved for future standard use".
Greg
Philipp Tomsich <philipp.tomsich@...>
There is no technical requirement for an alignment stricter than byte. Given that we are operating on a ‘config message’, there is also no implementation benefit of stricter alignment.
Reusing any low bits for other purposes will be error prone. If the mechanism is eventually superseded, we can still set its value to NIL (so, Tim’s suggestion is a conditio sine qua non in moving this forward!) and fall through to probe the (then) next-generation mechanism.
Philipp.
On Mon 28. Jun 2021 at 22:29, Tim Newsome <tim@...> wrote:
One addition:If the CSR contains 0, software should assume there is no configuration structure.I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.TimOn Mon, Jun 28, 2021 at 1:02 PM Tim Newsome <tim@...> wrote:On Mon, Jun 28, 2021 at 12:29 PM Greg Favor <gfavor@...> wrote:The 'mconfigptr' CSR is an MXLEN-wide R/W M-mode CSR that provides a system physical address pointer to a memory-resident config data structure to be used by a software method for low-level discovery of configuration information about harts and the rest of the system. Some implementations may hardwire this CSR to a suitable value. The assigned CSR number is 0x750.Why is the CSR writable? What's the use case for that? (Hypervisor writing it for an M mode system underneath? But then it's still not writable in M mode.)Tim
Philipp Tomsich <philipp.tomsich@...>
On Mon 28. Jun 2021 at 22:40, Greg Favor <gfavor@...> wrote:
On Mon, Jun 28, 2021 at 1:29 PM Tim Newsome <tim@...> wrote:One addition:If the CSR contains 0, software should assume there is no configuration structure.Agreed.I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.That's OK. The extension would then define the low two bits as "00" and as "Reserved for future standard use".
In consideration of low-end systems that may point into some memory-mapped serial storage, I would rather avoid this.
It’s also going to cause eventual discussions, once the first devices with errata slip through and cause issues with software ghat assumes this constraint to always hold.
Philipp.
Greg Favor
On Mon, Jun 28, 2021 at 1:54 PM Philipp Tomsich <philipp.tomsich@...> wrote:
I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.In consideration of low-end systems that may point into some memory-mapped serial storage, I would rather avoid this.It’s also going to cause eventual discussions, once the first devices with errata slip through and cause issues with software ghat assumes this constraint to always hold.
Good point. As far as having two extra bits for the future, that future situation may need just one or two bits, or may need many bits.
This point - of requiring an aligned pointer or not - should be judged and justified based on the pros and cons of requiring such alignment. The current proposal allows flexibility for an implementation, a profile spec, or platform spec to impose an alignment restriction.
Greg
Tim Newsome <tim@...>
On Mon, Jun 28, 2021 at 1:54 PM Philipp Tomsich <philipp.tomsich@...> wrote:
I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.That's OK. The extension would then define the low two bits as "00" and as "Reserved for future standard use".In consideration of low-end systems that may point into some memory-mapped serial storage, I would rather avoid this.It’s also going to cause eventual discussions, once the first devices with errata slip through and cause issues with software ghat assumes this constraint to always hold.
Fair enough. We can invent other mechanisms for future use if needed.
Tim