SBI extension proposal v2

SBI extension proposal v2

[Atish Patra]

Hi,
I have updated the proposal based on feedback received on previous 
version. This version has a better scalable SBI Function ID
numbering scheme. I have adopted markdown formatting for github docs.

If you prefer a github interface, it's available here as well.

https://github.com/riscv/riscv-sbi-doc/pull/12

Looking forward to your feedback.

Regards,
Atish
------------------------------------------------------------------------

## Introduction:
This is a proposal to make SBI a flexible and extensible interface.
It is based on the foundation policy of RISC-V i.e. modularity and
openness. The proposal tries to introduces very few new mandatory SBI 
Functions, that are absolutely required to maintain backward 
compatibility. Everything else is optional so that it remains an open 
standard yet robust.

The current RISC-V SBI only defines a few mandatory functions such as
inter-processor interrupts (IPI) interface, reprogramming timer, serial
console, and memory barrier instructions. The existing SBI documentation
can be found here [1]. Many important functionalities such as power
management/cpu-hotplug are not yet defined due to difficulties in
accommodating modifications without breaking the backward compatibility
with the current interface.

The proposed design is inspired by Power State Coordination Interface 
(PSCI) from ARM world. However, it adds only two new mandatory SBI calls 
providing version information and supported Functions, unlike PSCI where 
a significant number of functions are mandatory. The version of the 
existing SBI will be defined as a minimum version(0.1) which will always 
be backward compatible. Similarly, any Linux kernel with a newer feature 
will fall back if an older version of SBI does not support the updated 
capabilities. Both the operating system and SEE can be implemented to be 
two way backward compatible.

## SBI Calling Conventions (TODO)
There are some suggestions[3] to distinguish between SBI function return 
value and SBI calling sequence return value. Here are the few possible 
discussed ideas.

1. Return a single value, but values in the range {-511, -1} are 
considered errors, whereas return values in the range {0, 2^XLEN-512} 
are considered success.

2. Every SBI function call may return the following structure
```
struct valerr {
   long value;
   long error;
};
```
According to the RISC-V ABI spec[4], both a0 & a1 registers can be used 
for function return values.

3. Introduce an extra argument that can return error by reference.
```
/* Returns the CPU that was started.
  * @err indicates an error ID if one occurred, otherwise 0.
  * @err can be NULL if no error detection is required.
*/
int start_cpu(int cpu_num,..., Error *err);
```
Both approaches (2 & 3) will work, but there will be two versions of 
existing SBI functions to maintain the compatibility.

## SBI Functions:

A SBI function is an individual feature that SBI interface provides to 
supervisor mode from machine mode. Each function ID is assigned as per 
below section.

#### SBI Function ID numbering scheme:
A Function Set is a group of SBI functions which collectively implement 
similar kind of feature/functionality. The function ID numbering scheme 
need to be scalable in the future. At the same time, function validation 
check should be as quick as possible. Keeping these two requirements in 
mind, a hybrid function ID scheme is proposed.

SBI Function ID is u32 type.

```
31            24                        0
-----------------------------------------
|O|            |                        |
-----------------------------------------
Function Set   | Function Type          |
```
Bit[31]    =  ID overflow bit

Bit[30:24] =  Function Set

Bit[23:0]  =  Function Type within Function Set

The Function set is Bits [31:24] describing both function set number and 
overflow bit. In the beginning, the overflow bit should be set to 
**zero** and the function Type per function set can be assigned by left 
shifting 1 bit at a time. The overflow bit can be set to one **only** 
when we need to allocate more than 24 functions per function set in 
future. Setting the overflow bit will indicate an integer function type 
scheme. Thus, there will more than enough function IDs available to use 
in the future. Refer appendix 1 for examples.

Here are few Function Sets for SBI v0.2:

| Function Set         | Value  | Description 
       |
| -------------------  |:------:| 
:--------------------------------------------|
| Base Functions       | 0x00   | Base Functions mandatory for any SBI 
version |
| HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for 
per-Hart power management|
| System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for 
system-level power management|
| Vendor Functions     | 0x7f   | Vendor specific Functions|

N.B. There is a possibility that different vendors can choose to assign 
the same function numbers for different functionality. That's why vendor 
specific strings in Device Tree/ACPI or any other hardware description 
document can be used to verify if a specific Function belongs to the 
intended vendor or not.

# SBI Function List in both SBI v0.2 and v0.1

|Function Type              | Function Set      | ID(v0.2)     |ID (v0.1)  |
|---------------------------| ------------------|:------------:|:---------:|
| sbi_set_timer             | Base              | 0x00 000000  |0          |
| sbi_console_putchar       | Base              | 0x00 000001  |1          |
| sbi_console_getchar       | Base              | 0x00 000002  |2          |
| sbi_clear_ipi             | Base              | 0x00 000004  |3          |
| sbi_send_ipi              | Base              | 0x00 000008  |4          |
| sbi_remote_fence_i        | Base              | 0x00 000010  |5          |
| sbi_remote_sfence_vma     | Base              | 0x00 000020  |6          |
| sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7          |
| sbi_shutdown              | System PM         | 0x02 000000  |8          |
| sbi_system_reset          | System PM         | 0x02 000001  |-          |
| sbi_get_version           | Base              | 0x00 000080  |-          |
| sbi_get_function_mask     | Base              | 0x00 000100  |-          |
| sbi_get_function_count    | Base              | 0x00 000200  |-          |
| sbi_hart_up               | Hart PM           | 0x01 000000  |-          |
| sbi_hart_down             | Hart PM           | 0x01 000001  |-          |
| sbi_hart_suspend          | Hart PM           | 0x01 000002  |-          |
| sbi_hart_state            | Hart PM           | 0x01 000004  |-          |

#### Function Description

This section describes every newly introduced(in v0.2) function in 
details. Please refer to [1] for any v0.1 functions.

```
u32 sbi_get_version(void):
```
Returns the current SBI version implemented by the firmware.
version: uint32: Bits[31:16] Major Version
              Bits[15:0] Minor Version

The existing SBI version can be 0.1. The proposed version will be at 0.2
A different major version may indicate possible incompatible functions.
A different minor version must be compatible with each other even if
they have a higher number of features.

```
u32 sbi_get_function_mask(u32 ftype)
```
Given a function set type, it returns a bitmask of all functions IDs 
that are implemented for that function set.

```
u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long count):
```

This is a **reserved** function that should only be used if overflow bit 
in SBI function ID is set.

Accepts a start_Function_id as an argument and returns if 
start_Function_id to (start_Function_id + count - 1) are supported or not.

A count can help in minimizing the number of the M-mode traps by 
checking a range of SBI functions together.

```
int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
long priv)
```
Brings up "hartid" either during initial boot or after a sbi_hart_down
SBI call.

"start" points to a runtime-specified address where a hart can enter
into supervisor mode. This must be a physical address.

"priv" is a private data that caller can use to pass information about
execution context.

Return the appropriate SBI error code.

```
int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
long priv)
```
Suspends the calling hart to a particular power state. Suspended hart
will automatically wake-up based on some wakeup events at resume_entry
physical address.

"priv" is a private data that caller can use to pass information about
execution context. The SBI implementation must save a copy so that
caller can reuse while restoring hart from suspend.

Return the appropriate SBI error code.

```
int sbi_hart_down()
```
It powers off the hart and will be used in cpu-hotplug.
Only individual hart can remove itself from supervisor mode. It can be
moved to normal state only by sbi_hart_up function.

Return the appropriate SBI error code.

```
u32 sbi_hart_state(unsigned long hartid)
```
Returns the RISCV_POWER_STATE for a specific hartid. This will help make
kexec like functionality more robust.

```
void sbi_system_reset(u32 reset_type)
```
Reset the entire system.

## Return error code Table:
Here are the SBI return error codes defined.

| Error Type               | Value  |
| -------------------------|:------:|
|  SBI_ERR_SUCCESS         |  0     |
|  SBI_ERR_FAILURE         | -1     |
|  SBI_ERR_NOT_SUPPORTED   | -2     |
|  SBI_ERR_INVALID_PARAM   | -3     |
|  SBI_ERR_DENIED          | -4     |
|  SBI_ERR_INVALID_ADDRESS | -5     |


## Power State
A RISC-V core can exist in any of the following power states.

| Power states         | Value  | Description 
       |
| ------------------- 
|:------:|:---------------------------------------------|
| RISCV_HART_ON        | 0      | Powered up & operational. 
       |
| RISCV_HART_STANDBY   | 1      | Powered up but at reduced energy <br> 
consumption WFI instruction can be used to achieve this state|
| RISCV_HART_RETENTION | 2      | Deeper low power state. No reset <br> 
required but higher wakeup latency|
| RISCV_HART_OFF       | 3      | Powered off. Reset of the core 
required after power restore|

**_TODO_**:

We probably also need deeper hart power states or system-level power 
state reporting at some point, and non-HART components (caches, memory, 
etc).  Likely aligned with platform specs, once those start to show up.

## Implementation
Currently, SBI is implemented as a part of BBL. There is a different SBI 
implementation available in coreboot as well.

Alternatively, a separate open BSD/MIT licensed SBI project can be 
created that can be used by anybody to avoid this kind of SBI 
fragmentation. This project can generate both a firmware binary (to be 
executed directly in M mode) or a static library that can be used by 
different boot loaders. It will also help individual bootloaders
to either work from M or S mode without a separate SBI implementation.

## Conclusion
This proposal is far from perfect and absolutely any suggestion is 
welcome. Obviously, there are many other functionalities that can be 
added to this proposal. However, I just wanted to start with something 
that is an incremental change at best to kick off the discussion. The 
aim here is to initiate a discussion that can lead to a robust SBI 
specification.

## Reference:

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

[2] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md

[3] https://github.com/riscv/riscv-sbi-doc/pull/9

[4] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

## Appendix

1. Overflow Reserved bit example.

Let's choose function set type as Hart PM (0x1)

Function1 : 0x01 000001<br>
Function2 : 0x01 000002<br>
Function3 : 0x01 000004<br>
.<br>
.<br>
.<br>
Function24:0x01 800000<br>

At this point in future, Let's say we need more function IDs for Hart 
PM. The scheme can be switched to an integer scheme by setting the 
overflow bit.

Function25: 0x81 000001<br>
Function26: 0x81 000002<br>
Function27: 0x81 000003<br>
Function28: 0x81 000004<br>
.<br>
.<br>
Function34: 0x81 00000A<br>
.<br>

SBI extension proposal v2

[Atish Patra]

Hi,
I have updated the proposal based on feedback received on previous 
version. This version has a better scalable SBI Function ID
numbering scheme. I have adopted markdown formatting for github docs.

If you prefer a github interface, it's available here as well.

https://github.com/riscv/riscv-sbi-doc/pull/12

Looking forward to your feedback.

Regards,
Atish
------------------------------------------------------------------------

## Introduction:
This is a proposal to make SBI a flexible and extensible interface.
It is based on the foundation policy of RISC-V i.e. modularity and
openness. The proposal tries to introduces very few new mandatory SBI 
Functions, that are absolutely required to maintain backward 
compatibility. Everything else is optional so that it remains an open 
standard yet robust.

The current RISC-V SBI only defines a few mandatory functions such as
inter-processor interrupts (IPI) interface, reprogramming timer, serial
console, and memory barrier instructions. The existing SBI documentation
can be found here [1]. Many important functionalities such as power
management/cpu-hotplug are not yet defined due to difficulties in
accommodating modifications without breaking the backward compatibility
with the current interface.

The proposed design is inspired by Power State Coordination Interface 
(PSCI) from ARM world. However, it adds only two new mandatory SBI calls 
providing version information and supported Functions, unlike PSCI where 
a significant number of functions are mandatory. The version of the 
existing SBI will be defined as a minimum version(0.1) which will always 
be backward compatible. Similarly, any Linux kernel with a newer feature 
will fall back if an older version of SBI does not support the updated 
capabilities. Both the operating system and SEE can be implemented to be 
two way backward compatible.

## SBI Calling Conventions (TODO)
There are some suggestions[3] to distinguish between SBI function return 
value and SBI calling sequence return value. Here are the few possible 
discussed ideas.

1. Return a single value, but values in the range {-511, -1} are 
considered errors, whereas return values in the range {0, 2^XLEN-512} 
are considered success.

2. Every SBI function call may return the following structure
```
struct valerr {
   long value;
   long error;
};
```
According to the RISC-V ABI spec[4], both a0 & a1 registers can be used 
for function return values.

3. Introduce an extra argument that can return error by reference.
```
/* Returns the CPU that was started.
  * @err indicates an error ID if one occurred, otherwise 0.
  * @err can be NULL if no error detection is required.
*/
int start_cpu(int cpu_num,..., Error *err);
```
Both approaches (2 & 3) will work, but there will be two versions of 
existing SBI functions to maintain the compatibility.

## SBI Functions:

A SBI function is an individual feature that SBI interface provides to 
supervisor mode from machine mode. Each function ID is assigned as per 
below section.

#### SBI Function ID numbering scheme:
A Function Set is a group of SBI functions which collectively implement 
similar kind of feature/functionality. The function ID numbering scheme 
need to be scalable in the future. At the same time, function validation 
check should be as quick as possible. Keeping these two requirements in 
mind, a hybrid function ID scheme is proposed.

SBI Function ID is u32 type.

```
31            24                        0
-----------------------------------------
|O|            |                        |
-----------------------------------------
Function Set   | Function Type          |
```
Bit[31]    =  ID overflow bit

Bit[30:24] =  Function Set

Bit[23:0]  =  Function Type within Function Set

The Function set is Bits [31:24] describing both function set number and 
overflow bit. In the beginning, the overflow bit should be set to 
**zero** and the function Type per function set can be assigned by left 
shifting 1 bit at a time. The overflow bit can be set to one **only** 
when we need to allocate more than 24 functions per function set in 
future. Setting the overflow bit will indicate an integer function type 
scheme. Thus, there will more than enough function IDs available to use 
in the future. Refer appendix 1 for examples.

Here are few Function Sets for SBI v0.2:

| Function Set         | Value  | Description 
       |
| -------------------  |:------:| 
:--------------------------------------------|
| Base Functions       | 0x00   | Base Functions mandatory for any SBI 
version |
| HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for 
per-Hart power management|
| System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for 
system-level power management|
| Vendor Functions     | 0x7f   | Vendor specific Functions|

N.B. There is a possibility that different vendors can choose to assign 
the same function numbers for different functionality. That's why vendor 
specific strings in Device Tree/ACPI or any other hardware description 
document can be used to verify if a specific Function belongs to the 
intended vendor or not.

# SBI Function List in both SBI v0.2 and v0.1

|Function Type              | Function Set      | ID(v0.2)     |ID (v0.1)  |
|---------------------------| ------------------|:------------:|:---------:|
| sbi_set_timer             | Base              | 0x00 000000  |0          |
| sbi_console_putchar       | Base              | 0x00 000001  |1          |
| sbi_console_getchar       | Base              | 0x00 000002  |2          |
| sbi_clear_ipi             | Base              | 0x00 000004  |3          |
| sbi_send_ipi              | Base              | 0x00 000008  |4          |
| sbi_remote_fence_i        | Base              | 0x00 000010  |5          |
| sbi_remote_sfence_vma     | Base              | 0x00 000020  |6          |
| sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7          |
| sbi_shutdown              | System PM         | 0x02 000000  |8          |
| sbi_system_reset          | System PM         | 0x02 000001  |-          |
| sbi_get_version           | Base              | 0x00 000080  |-          |
| sbi_get_function_mask     | Base              | 0x00 000100  |-          |
| sbi_get_function_count    | Base              | 0x00 000200  |-          |
| sbi_hart_up               | Hart PM           | 0x01 000000  |-          |
| sbi_hart_down             | Hart PM           | 0x01 000001  |-          |
| sbi_hart_suspend          | Hart PM           | 0x01 000002  |-          |
| sbi_hart_state            | Hart PM           | 0x01 000004  |-          |

#### Function Description

This section describes every newly introduced(in v0.2) function in 
details. Please refer to [1] for any v0.1 functions.

```
u32 sbi_get_version(void):
```
Returns the current SBI version implemented by the firmware.
version: uint32: Bits[31:16] Major Version
              Bits[15:0] Minor Version

The existing SBI version can be 0.1. The proposed version will be at 0.2
A different major version may indicate possible incompatible functions.
A different minor version must be compatible with each other even if
they have a higher number of features.

```
u32 sbi_get_function_mask(u32 ftype)
```
Given a function set type, it returns a bitmask of all functions IDs 
that are implemented for that function set.

```
u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long count):
```

This is a **reserved** function that should only be used if overflow bit 
in SBI function ID is set.

Accepts a start_Function_id as an argument and returns if 
start_Function_id to (start_Function_id + count - 1) are supported or not.

A count can help in minimizing the number of the M-mode traps by 
checking a range of SBI functions together.

```
int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
long priv)
```
Brings up "hartid" either during initial boot or after a sbi_hart_down
SBI call.

"start" points to a runtime-specified address where a hart can enter
into supervisor mode. This must be a physical address.

"priv" is a private data that caller can use to pass information about
execution context.

Return the appropriate SBI error code.

```
int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
long priv)
```
Suspends the calling hart to a particular power state. Suspended hart
will automatically wake-up based on some wakeup events at resume_entry
physical address.

"priv" is a private data that caller can use to pass information about
execution context. The SBI implementation must save a copy so that
caller can reuse while restoring hart from suspend.

Return the appropriate SBI error code.

```
int sbi_hart_down()
```
It powers off the hart and will be used in cpu-hotplug.
Only individual hart can remove itself from supervisor mode. It can be
moved to normal state only by sbi_hart_up function.

Return the appropriate SBI error code.

```
u32 sbi_hart_state(unsigned long hartid)
```
Returns the RISCV_POWER_STATE for a specific hartid. This will help make
kexec like functionality more robust.

```
void sbi_system_reset(u32 reset_type)
```
Reset the entire system.

## Return error code Table:
Here are the SBI return error codes defined.

| Error Type               | Value  |
| -------------------------|:------:|
|  SBI_ERR_SUCCESS         |  0     |
|  SBI_ERR_FAILURE         | -1     |
|  SBI_ERR_NOT_SUPPORTED   | -2     |
|  SBI_ERR_INVALID_PARAM   | -3     |
|  SBI_ERR_DENIED          | -4     |
|  SBI_ERR_INVALID_ADDRESS | -5     |


## Power State
A RISC-V core can exist in any of the following power states.

| Power states         | Value  | Description 
       |
| ------------------- 
|:------:|:---------------------------------------------|
| RISCV_HART_ON        | 0      | Powered up & operational. 
       |
| RISCV_HART_STANDBY   | 1      | Powered up but at reduced energy <br> 
consumption WFI instruction can be used to achieve this state|
| RISCV_HART_RETENTION | 2      | Deeper low power state. No reset <br> 
required but higher wakeup latency|
| RISCV_HART_OFF       | 3      | Powered off. Reset of the core 
required after power restore|

**_TODO_**:

We probably also need deeper hart power states or system-level power 
state reporting at some point, and non-HART components (caches, memory, 
etc).  Likely aligned with platform specs, once those start to show up.

## Implementation
Currently, SBI is implemented as a part of BBL. There is a different SBI 
implementation available in coreboot as well.

Alternatively, a separate open BSD/MIT licensed SBI project can be 
created that can be used by anybody to avoid this kind of SBI 
fragmentation. This project can generate both a firmware binary (to be 
executed directly in M mode) or a static library that can be used by 
different boot loaders. It will also help individual bootloaders
to either work from M or S mode without a separate SBI implementation.

## Conclusion
This proposal is far from perfect and absolutely any suggestion is 
welcome. Obviously, there are many other functionalities that can be 
added to this proposal. However, I just wanted to start with something 
that is an incremental change at best to kick off the discussion. The 
aim here is to initiate a discussion that can lead to a robust SBI 
specification.

## Reference:

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf

[2] https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.md

[3] https://github.com/riscv/riscv-sbi-doc/pull/9

[4] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

## Appendix

1. Overflow Reserved bit example.

Let's choose function set type as Hart PM (0x1)

Function1 : 0x01 000001<br>
Function2 : 0x01 000002<br>
Function3 : 0x01 000004<br>
.<br>
.<br>
.<br>
Function24:0x01 800000<br>

At this point in future, Let's say we need more function IDs for Hart 
PM. The scheme can be switched to an integer scheme by setting the 
overflow bit.

Function25: 0x81 000001<br>
Function26: 0x81 000002<br>
Function27: 0x81 000003<br>
Function28: 0x81 000004<br>
.<br>
.<br>
Function34: 0x81 00000A<br>
.<br>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> wrote:

> ## Conclusion
> This proposal is far from perfect and absolutely any suggestion is
> welcome. Obviously, there are many other functionalities that can be
> added to this proposal. However, I just wanted to start with something
> that is an incremental change at best to kick off the discussion. The
> aim here is to initiate a discussion that can lead to a robust SBI
> specification.

 very cool, atish.

 i would very much like to see the optional addition of multiple
serial lines, by adding a getchar and putchar function that takes just
one extra argument: the serial line index.

 there are a lot of different uses to which mult-serial lines may be put:

 * boot message separation from console login
 * boot management separation from other purposes (u-boot/coreboot)
 * virtual /dev/ttyS0-3
 * clean UPS reporting and management
 * remote virtual machine power management (power-on / off)
 * simple bog-standard multiple virtual login consoles
 * separation of debug messages (stdout/stderr) to ease debugging and
development
 * remote and virtual OpenOCD and kernel debugging without disrupting
the main serial console
 * PPP serial links.

this latter is one that i am particularly interested in, as i would
like to be able to boot a full GNU/Linux OS on spike, given the lower
barrier to entry in making modifications and experimenting with spike
than it is with qemu.

 if spike were able, through a multi-serial SBI interface, to have a
PPP serial line, it would be possible to run a root NFS (or other
network block device) without having to sacrifice console access.  it
would be possible to create an initramfs from a lower-capability
system like buildroot, containing PPP, enable it, and pivot-root out
to a full stock GNU/Linux OS such as debian or fedora.

 so there are huge benefits, reducing the development barrier to entry
into RISC-V experimentation and debugging, and opening up a much wider
range of capabilities and possibilities for machine and virtual system
management.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> wrote:

> ## Conclusion
> This proposal is far from perfect and absolutely any suggestion is
> welcome. Obviously, there are many other functionalities that can be
> added to this proposal. However, I just wanted to start with something
> that is an incremental change at best to kick off the discussion. The
> aim here is to initiate a discussion that can lead to a robust SBI
> specification.

 very cool, atish.

 i would very much like to see the optional addition of multiple
serial lines, by adding a getchar and putchar function that takes just
one extra argument: the serial line index.

 there are a lot of different uses to which mult-serial lines may be put:

 * boot message separation from console login
 * boot management separation from other purposes (u-boot/coreboot)
 * virtual /dev/ttyS0-3
 * clean UPS reporting and management
 * remote virtual machine power management (power-on / off)
 * simple bog-standard multiple virtual login consoles
 * separation of debug messages (stdout/stderr) to ease debugging and
development
 * remote and virtual OpenOCD and kernel debugging without disrupting
the main serial console
 * PPP serial links.

this latter is one that i am particularly interested in, as i would
like to be able to boot a full GNU/Linux OS on spike, given the lower
barrier to entry in making modifications and experimenting with spike
than it is with qemu.

 if spike were able, through a multi-serial SBI interface, to have a
PPP serial line, it would be possible to run a root NFS (or other
network block device) without having to sacrifice console access.  it
would be possible to create an initramfs from a lower-capability
system like buildroot, containing PPP, enable it, and pivot-root out
to a full stock GNU/Linux OS such as debian or fedora.

 so there are huge benefits, reducing the development barrier to entry
into RISC-V experimentation and debugging, and opening up a much wider
range of capabilities and possibilities for machine and virtual system
management.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> 
> wrote:
> 
>> ## Conclusion
>> This proposal is far from perfect and absolutely any suggestion is
>> welcome. Obviously, there are many other functionalities that can be
>> added to this proposal. However, I just wanted to start with something
>> that is an incremental change at best to kick off the discussion. The
>> aim here is to initiate a discussion that can lead to a robust SBI
>> specification.
> 
>  very cool, atish.
> 
>  i would very much like to see the optional addition of multiple
> serial lines, by adding a getchar and putchar function that takes just
> one extra argument: the serial line index.
> 
>  there are a lot of different uses to which mult-serial lines may be 
> put:
> 
>  * boot message separation from console login
>  * boot management separation from other purposes (u-boot/coreboot)
>  * virtual /dev/ttyS0-3
>  * clean UPS reporting and management
>  * remote virtual machine power management (power-on / off)
>  * simple bog-standard multiple virtual login consoles
>  * separation of debug messages (stdout/stderr) to ease debugging and
> development
>  * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
>  * PPP serial links.
> 
> this latter is one that i am particularly interested in, as i would
> like to be able to boot a full GNU/Linux OS on spike, given the lower
> barrier to entry in making modifications and experimenting with spike
> than it is with qemu.
> 
>  if spike were able, through a multi-serial SBI interface, to have a
> PPP serial line, it would be possible to run a root NFS (or other
> network block device) without having to sacrifice console access.  it
> would be possible to create an initramfs from a lower-capability
> system like buildroot, containing PPP, enable it, and pivot-root out
> to a full stock GNU/Linux OS such as debian or fedora.
> 
>  so there are huge benefits, reducing the development barrier to entry
> into RISC-V experimentation and debugging, and opening up a much wider
> range of capabilities and possibilities for machine and virtual system
> management.
> 
> l.


The current SBI says that console_getchar/console_putchar are for the 
debug
console but on Linux we use them for the main console on earlyprintk. I
think it's misleading and we should at least have an argument to chose
between the main console and an optional debug console, or rename
them to debug_console_getchar/debug_console_putchar and 
main_console_getchar/
main_console_putchar.

However I don't think that argument should be the serial line. Different
vendors may use different serial lines for the main console / debug 
console,
the caller doesn't know which serial line maps to which console, so the 
SBI
should be more abstract and use something like a console id where e.g. 0 
is
main console an 1 is debug.

Regards,
Nick

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> 
> wrote:
> 
>> ## Conclusion
>> This proposal is far from perfect and absolutely any suggestion is
>> welcome. Obviously, there are many other functionalities that can be
>> added to this proposal. However, I just wanted to start with something
>> that is an incremental change at best to kick off the discussion. The
>> aim here is to initiate a discussion that can lead to a robust SBI
>> specification.
> 
>  very cool, atish.
> 
>  i would very much like to see the optional addition of multiple
> serial lines, by adding a getchar and putchar function that takes just
> one extra argument: the serial line index.
> 
>  there are a lot of different uses to which mult-serial lines may be 
> put:
> 
>  * boot message separation from console login
>  * boot management separation from other purposes (u-boot/coreboot)
>  * virtual /dev/ttyS0-3
>  * clean UPS reporting and management
>  * remote virtual machine power management (power-on / off)
>  * simple bog-standard multiple virtual login consoles
>  * separation of debug messages (stdout/stderr) to ease debugging and
> development
>  * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
>  * PPP serial links.
> 
> this latter is one that i am particularly interested in, as i would
> like to be able to boot a full GNU/Linux OS on spike, given the lower
> barrier to entry in making modifications and experimenting with spike
> than it is with qemu.
> 
>  if spike were able, through a multi-serial SBI interface, to have a
> PPP serial line, it would be possible to run a root NFS (or other
> network block device) without having to sacrifice console access.  it
> would be possible to create an initramfs from a lower-capability
> system like buildroot, containing PPP, enable it, and pivot-root out
> to a full stock GNU/Linux OS such as debian or fedora.
> 
>  so there are huge benefits, reducing the development barrier to entry
> into RISC-V experimentation and debugging, and opening up a much wider
> range of capabilities and possibilities for machine and virtual system
> management.
> 
> l.


The current SBI says that console_getchar/console_putchar are for the 
debug
console but on Linux we use them for the main console on earlyprintk. I
think it's misleading and we should at least have an argument to chose
between the main console and an optional debug console, or rename
them to debug_console_getchar/debug_console_putchar and 
main_console_getchar/
main_console_putchar.

However I don't think that argument should be the serial line. Different
vendors may use different serial lines for the main console / debug 
console,
the caller doesn't know which serial line maps to which console, so the 
SBI
should be more abstract and use something like a console id where e.g. 0 
is
main console an 1 is debug.

Regards,
Nick

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > wrote:
> >
> >> ## Conclusion
> >> This proposal is far from perfect and absolutely any suggestion is
> >> welcome. Obviously, there are many other functionalities that can be
> >> added to this proposal. However, I just wanted to start with something
> >> that is an incremental change at best to kick off the discussion. The
> >> aim here is to initiate a discussion that can lead to a robust SBI
> >> specification.
> >
> >  very cool, atish.
> >
> >  i would very much like to see the optional addition of multiple
> > serial lines, by adding a getchar and putchar function that takes just
> > one extra argument: the serial line index.
> >
> >  there are a lot of different uses to which mult-serial lines may be
> > put:
> >
> >  * boot message separation from console login
> >  * boot management separation from other purposes (u-boot/coreboot)
> >  * virtual /dev/ttyS0-3
> >  * clean UPS reporting and management
> >  * remote virtual machine power management (power-on / off)
> >  * simple bog-standard multiple virtual login consoles
> >  * separation of debug messages (stdout/stderr) to ease debugging and
> > development
> >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > the main serial console
> >  * PPP serial links.
> >
> > this latter is one that i am particularly interested in, as i would
> > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > barrier to entry in making modifications and experimenting with spike
> > than it is with qemu.
> >
> >  if spike were able, through a multi-serial SBI interface, to have a
> > PPP serial line, it would be possible to run a root NFS (or other
> > network block device) without having to sacrifice console access.  it
> > would be possible to create an initramfs from a lower-capability
> > system like buildroot, containing PPP, enable it, and pivot-root out
> > to a full stock GNU/Linux OS such as debian or fedora.
> >
> >  so there are huge benefits, reducing the development barrier to entry
> > into RISC-V experimentation and debugging, and opening up a much wider
> > range of capabilities and possibilities for machine and virtual system
> > management.
> >
> > l.
>
>
> The current SBI says that console_getchar/console_putchar are for the
> debug
> console but on Linux we use them for the main console on earlyprintk.

 ... yeah exactly.  and what if something goes wrong, you want to be
able to interact over openocd without interfering with that
earlyprintk, particularly during that critical first bringup phase of
real-world silicon?

> I
> think it's misleading and we should at least have an argument to chose
> between the main console and an optional debug console, or rename
> them to debug_console_getchar/debug_console_putchar and
> main_console_getchar/
> main_console_putchar.

 i initially thought of proposing that, however:

 (1) the API already exists with "single console". it would therefore
be disruptive to change that

 (2) if adding something called debug_console_{get/put}char, it might
as well take advantage of the opportunity to be extended and made
generic, and have the extra argument added

> However I don't think that argument should be the serial line. Different
> vendors may use different serial lines for the main console / debug
> console,
> the caller doesn't know which serial line maps to which console, so the
> SBI
> should be more abstract and use something like a console id where e.g. 0
> is
> main console an 1 is debug.

 yes, it should [have]: my feeling is, it's a little late in the game
given that it's almost certainly baked into pre-existing hardware, by
now, so the next best thing is a new function call.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > wrote:
> >
> >> ## Conclusion
> >> This proposal is far from perfect and absolutely any suggestion is
> >> welcome. Obviously, there are many other functionalities that can be
> >> added to this proposal. However, I just wanted to start with something
> >> that is an incremental change at best to kick off the discussion. The
> >> aim here is to initiate a discussion that can lead to a robust SBI
> >> specification.
> >
> >  very cool, atish.
> >
> >  i would very much like to see the optional addition of multiple
> > serial lines, by adding a getchar and putchar function that takes just
> > one extra argument: the serial line index.
> >
> >  there are a lot of different uses to which mult-serial lines may be
> > put:
> >
> >  * boot message separation from console login
> >  * boot management separation from other purposes (u-boot/coreboot)
> >  * virtual /dev/ttyS0-3
> >  * clean UPS reporting and management
> >  * remote virtual machine power management (power-on / off)
> >  * simple bog-standard multiple virtual login consoles
> >  * separation of debug messages (stdout/stderr) to ease debugging and
> > development
> >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > the main serial console
> >  * PPP serial links.
> >
> > this latter is one that i am particularly interested in, as i would
> > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > barrier to entry in making modifications and experimenting with spike
> > than it is with qemu.
> >
> >  if spike were able, through a multi-serial SBI interface, to have a
> > PPP serial line, it would be possible to run a root NFS (or other
> > network block device) without having to sacrifice console access.  it
> > would be possible to create an initramfs from a lower-capability
> > system like buildroot, containing PPP, enable it, and pivot-root out
> > to a full stock GNU/Linux OS such as debian or fedora.
> >
> >  so there are huge benefits, reducing the development barrier to entry
> > into RISC-V experimentation and debugging, and opening up a much wider
> > range of capabilities and possibilities for machine and virtual system
> > management.
> >
> > l.
>
>
> The current SBI says that console_getchar/console_putchar are for the
> debug
> console but on Linux we use them for the main console on earlyprintk.

 ... yeah exactly.  and what if something goes wrong, you want to be
able to interact over openocd without interfering with that
earlyprintk, particularly during that critical first bringup phase of
real-world silicon?

> I
> think it's misleading and we should at least have an argument to chose
> between the main console and an optional debug console, or rename
> them to debug_console_getchar/debug_console_putchar and
> main_console_getchar/
> main_console_putchar.

 i initially thought of proposing that, however:

 (1) the API already exists with "single console". it would therefore
be disruptive to change that

 (2) if adding something called debug_console_{get/put}char, it might
as well take advantage of the opportunity to be extended and made
generic, and have the extra argument added

> However I don't think that argument should be the serial line. Different
> vendors may use different serial lines for the main console / debug
> console,
> the caller doesn't know which serial line maps to which console, so the
> SBI
> should be more abstract and use something like a console id where e.g. 0
> is
> main console an 1 is debug.

 yes, it should [have]: my feeling is, it's a little late in the game
given that it's almost certainly baked into pre-existing hardware, by
now, so the next best thing is a new function call.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[ron minnich]

At Google and other places, we've been struggling now for years with
overly complex firmware that is implemented incorrectly, enabling
exploits and other bad things. The list of things vendors get wrong in
firmware, both enabling exploits and enabling others to enable
exploits, is long and it continues to this day. There is an
unbelievable amount of money out there all involving firmware
exploits, very little of it involving nice people.

I'm currently working on deleting all use of the x86 version of M
mode, i.e. SMM. There are many proposals out there for deleting SMM
from the architecture. I've also shown at a talk in 2017 how we could
redirect SMM interrupts back into the kernel. We're also removing all
use of callbacks into UEFI on x86. We're almost there.

Which is why I'm a bit unhappy to see this (to me) cancerous growth in
proposals for M- mode code. PPP in firmware? Really? multiple serial
devices? really? We've been here before, in the 1970s, with something
called the BIOS. If you're not familiar with it, go take a look, or
you can take my word for it that these proposals implement that idea.
We spent over 20 years freeing ourselves from it on x86. Why go back
to a 50 year old model on a CPU designed to be in use for 50 years?

My early understanding of M mode was that it was an Alpha PALCode like
thing, enabling access to resources that were behind a privilege wall.
I did not like it that much, but I was OK: it was very limited in
function, and the kernel could replace it, or at least measure it. I
also accept that every cpu vendor uses m mode like things (e.g. ARM
TF) for reasonable purposes and also (let's be honest here)  for
dealing with chipset mistakes. But that does not mean you need to
recreate BIOS.

The SBI should be hard to add to, deliberately. It should be used only
when there are no possible alternatives. It needs to be open source
and held in common. It should be possible for a kernel to replace or
at least measure it. And, further, there needs to be some work done on
why you add to it, and why you don't, with bias against adding to it.
This proposal works against those ideals, as it explicitly enables
vendor-specific forks of the SBI. Sure, this can happen, but why make
it so easy?

see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.

Also, I've had discussions with some security folks in our firmware
community about the fact that the PMP can be used in a way that the
kernel can not measure the SBI, since SBI might read-protect itself.
This is a real step backwards, FYI. Not sure if it can be changed at
this point.

ron
p.s. For interleaving debug and console output firmware, use the
oldest trick in the book: ASCII is 7 bits. Since console out is 8
bits, reserve 128 values for console out, and 128 for debug stream,
and if the debug stream needs 8 bit for some words, you know what to
do. It's very easy and doesn't require that we add multiple UART
support to SBI.
On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
> >
> > ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
> > > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > > wrote:
> > >
> > >> ## Conclusion
> > >> This proposal is far from perfect and absolutely any suggestion is
> > >> welcome. Obviously, there are many other functionalities that can be
> > >> added to this proposal. However, I just wanted to start with something
> > >> that is an incremental change at best to kick off the discussion. The
> > >> aim here is to initiate a discussion that can lead to a robust SBI
> > >> specification.
> > >
> > >  very cool, atish.
> > >
> > >  i would very much like to see the optional addition of multiple
> > > serial lines, by adding a getchar and putchar function that takes just
> > > one extra argument: the serial line index.
> > >
> > >  there are a lot of different uses to which mult-serial lines may be
> > > put:
> > >
> > >  * boot message separation from console login
> > >  * boot management separation from other purposes (u-boot/coreboot)
> > >  * virtual /dev/ttyS0-3
> > >  * clean UPS reporting and management
> > >  * remote virtual machine power management (power-on / off)
> > >  * simple bog-standard multiple virtual login consoles
> > >  * separation of debug messages (stdout/stderr) to ease debugging and
> > > development
> > >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > > the main serial console
> > >  * PPP serial links.
> > >
> > > this latter is one that i am particularly interested in, as i would
> > > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > > barrier to entry in making modifications and experimenting with spike
> > > than it is with qemu.
> > >
> > >  if spike were able, through a multi-serial SBI interface, to have a
> > > PPP serial line, it would be possible to run a root NFS (or other
> > > network block device) without having to sacrifice console access.  it
> > > would be possible to create an initramfs from a lower-capability
> > > system like buildroot, containing PPP, enable it, and pivot-root out
> > > to a full stock GNU/Linux OS such as debian or fedora.
> > >
> > >  so there are huge benefits, reducing the development barrier to entry
> > > into RISC-V experimentation and debugging, and opening up a much wider
> > > range of capabilities and possibilities for machine and virtual system
> > > management.
> > >
> > > l.
> >
> >
> > The current SBI says that console_getchar/console_putchar are for the
> > debug
> > console but on Linux we use them for the main console on earlyprintk.
>
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
>
> > I
> > think it's misleading and we should at least have an argument to chose
> > between the main console and an optional debug console, or rename
> > them to debug_console_getchar/debug_console_putchar and
> > main_console_getchar/
> > main_console_putchar.
>
>  i initially thought of proposing that, however:
>
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
>
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
>
> > However I don't think that argument should be the serial line. Different
> > vendors may use different serial lines for the main console / debug
> > console,
> > the caller doesn't know which serial line maps to which console, so the
> > SBI
> > should be more abstract and use something like a console id where e.g. 0
> > is
> > main console an 1 is debug.
>
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
>
> l.
>
> --
> 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 at groups.riscv.org.
> To post to this group, send email to sw-dev at 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/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

At Google and other places, we've been struggling now for years with
overly complex firmware that is implemented incorrectly, enabling
exploits and other bad things. The list of things vendors get wrong in
firmware, both enabling exploits and enabling others to enable
exploits, is long and it continues to this day. There is an
unbelievable amount of money out there all involving firmware
exploits, very little of it involving nice people.

I'm currently working on deleting all use of the x86 version of M
mode, i.e. SMM. There are many proposals out there for deleting SMM
from the architecture. I've also shown at a talk in 2017 how we could
redirect SMM interrupts back into the kernel. We're also removing all
use of callbacks into UEFI on x86. We're almost there.

Which is why I'm a bit unhappy to see this (to me) cancerous growth in
proposals for M- mode code. PPP in firmware? Really? multiple serial
devices? really? We've been here before, in the 1970s, with something
called the BIOS. If you're not familiar with it, go take a look, or
you can take my word for it that these proposals implement that idea.
We spent over 20 years freeing ourselves from it on x86. Why go back
to a 50 year old model on a CPU designed to be in use for 50 years?

My early understanding of M mode was that it was an Alpha PALCode like
thing, enabling access to resources that were behind a privilege wall.
I did not like it that much, but I was OK: it was very limited in
function, and the kernel could replace it, or at least measure it. I
also accept that every cpu vendor uses m mode like things (e.g. ARM
TF) for reasonable purposes and also (let's be honest here)  for
dealing with chipset mistakes. But that does not mean you need to
recreate BIOS.

The SBI should be hard to add to, deliberately. It should be used only
when there are no possible alternatives. It needs to be open source
and held in common. It should be possible for a kernel to replace or
at least measure it. And, further, there needs to be some work done on
why you add to it, and why you don't, with bias against adding to it.
This proposal works against those ideals, as it explicitly enables
vendor-specific forks of the SBI. Sure, this can happen, but why make
it so easy?

see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.

Also, I've had discussions with some security folks in our firmware
community about the fact that the PMP can be used in a way that the
kernel can not measure the SBI, since SBI might read-protect itself.
This is a real step backwards, FYI. Not sure if it can be changed at
this point.

ron
p.s. For interleaving debug and console output firmware, use the
oldest trick in the book: ASCII is 7 bits. Since console out is 8
bits, reserve 128 values for console out, and 128 for debug stream,
and if the debug stream needs 8 bit for some words, you know what to
do. It's very easy and doesn't require that we add multiple UART
support to SBI.
On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
> >
> > Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
> > > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
> > > wrote:
> > >
> > >> ## Conclusion
> > >> This proposal is far from perfect and absolutely any suggestion is
> > >> welcome. Obviously, there are many other functionalities that can be
> > >> added to this proposal. However, I just wanted to start with something
> > >> that is an incremental change at best to kick off the discussion. The
> > >> aim here is to initiate a discussion that can lead to a robust SBI
> > >> specification.
> > >
> > >  very cool, atish.
> > >
> > >  i would very much like to see the optional addition of multiple
> > > serial lines, by adding a getchar and putchar function that takes just
> > > one extra argument: the serial line index.
> > >
> > >  there are a lot of different uses to which mult-serial lines may be
> > > put:
> > >
> > >  * boot message separation from console login
> > >  * boot management separation from other purposes (u-boot/coreboot)
> > >  * virtual /dev/ttyS0-3
> > >  * clean UPS reporting and management
> > >  * remote virtual machine power management (power-on / off)
> > >  * simple bog-standard multiple virtual login consoles
> > >  * separation of debug messages (stdout/stderr) to ease debugging and
> > > development
> > >  * remote and virtual OpenOCD and kernel debugging without disrupting
> > > the main serial console
> > >  * PPP serial links.
> > >
> > > this latter is one that i am particularly interested in, as i would
> > > like to be able to boot a full GNU/Linux OS on spike, given the lower
> > > barrier to entry in making modifications and experimenting with spike
> > > than it is with qemu.
> > >
> > >  if spike were able, through a multi-serial SBI interface, to have a
> > > PPP serial line, it would be possible to run a root NFS (or other
> > > network block device) without having to sacrifice console access.  it
> > > would be possible to create an initramfs from a lower-capability
> > > system like buildroot, containing PPP, enable it, and pivot-root out
> > > to a full stock GNU/Linux OS such as debian or fedora.
> > >
> > >  so there are huge benefits, reducing the development barrier to entry
> > > into RISC-V experimentation and debugging, and opening up a much wider
> > > range of capabilities and possibilities for machine and virtual system
> > > management.
> > >
> > > l.
> >
> >
> > The current SBI says that console_getchar/console_putchar are for the
> > debug
> > console but on Linux we use them for the main console on earlyprintk.
>
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
>
> > I
> > think it's misleading and we should at least have an argument to chose
> > between the main console and an optional debug console, or rename
> > them to debug_console_getchar/debug_console_putchar and
> > main_console_getchar/
> > main_console_putchar.
>
>  i initially thought of proposing that, however:
>
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
>
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
>
> > However I don't think that argument should be the serial line. Different
> > vendors may use different serial lines for the main console / debug
> > console,
> > the caller doesn't know which serial line maps to which console, so the
> > SBI
> > should be more abstract and use something like a console id where e.g. 0
> > is
> > main console an 1 is debug.
>
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
>
> l.
>
> --
> 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-dev@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/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 4:46 PM ron minnich <rminnich@gmail.com> wrote:

> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware?

 no, ron, absolutely not, that would not make any sense at all:
getting what is otherwise a userspace pppd into firmware would be a
nightmare as it would require a huge amount of POSIX support dragged
in with it.

 it would be ppp running in spike userspace (buildroot in an
initramfs), where the linux kernel would have absolutely standard ppp
modules compiled up, the serial data drops down to spike over the
proposed modified SBI, which, on having support for the proposed
addition, will take an extra command-line option "spike
--serial-line-0-redirect-cmd='pppd'" which gets it into the host, and
the guest spike OS gets network in a dead straightforward fashion, for
very little in the way of code and ABI modifications.

 it's a cut/paste job, for goodness sake, in the pre-existing SBI
implementations, just adding an extra argument.

 it's real simple, and has absolutely nothing to do with the [crazed!]
idea of porting a userspace ppp POSIX daemon into u-boot/coreboot.  i
mean, you *could* do it but you'd be insane to consider it, and there
are better options for the more complex systems... which don't *have*
to use the proposed idea.

 the alternative to achieve the same desired goal is to re-wire all of
the u-boot/coreboot source code and use some form of serial line
"framing" protocol, to emulate multiple virtual serial lines over the
single SBI console.  and rewrite openocd to support it.  and. and.
and. and.

 that's a lairy nightmare waiting to happen, and, on early debug of
real silicon where you're hand-programming the PLL and the serial
port's outputting crap because you've no idea of the baud rate, you
wouldn't see ASCII characters if you got it right, you'd see framing
crap instead and couldn't plug in simple minicom, it'd have to be a
*modified* version of minicom.  etc. etc. etc. etc.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

 naah.  see above.  it's a lot more complex and fragile than that.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 4:46 PM ron minnich <rminnich@gmail.com> wrote:

> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware?

 no, ron, absolutely not, that would not make any sense at all:
getting what is otherwise a userspace pppd into firmware would be a
nightmare as it would require a huge amount of POSIX support dragged
in with it.

 it would be ppp running in spike userspace (buildroot in an
initramfs), where the linux kernel would have absolutely standard ppp
modules compiled up, the serial data drops down to spike over the
proposed modified SBI, which, on having support for the proposed
addition, will take an extra command-line option "spike
--serial-line-0-redirect-cmd='pppd'" which gets it into the host, and
the guest spike OS gets network in a dead straightforward fashion, for
very little in the way of code and ABI modifications.

 it's a cut/paste job, for goodness sake, in the pre-existing SBI
implementations, just adding an extra argument.

 it's real simple, and has absolutely nothing to do with the [crazed!]
idea of porting a userspace ppp POSIX daemon into u-boot/coreboot.  i
mean, you *could* do it but you'd be insane to consider it, and there
are better options for the more complex systems... which don't *have*
to use the proposed idea.

 the alternative to achieve the same desired goal is to re-wire all of
the u-boot/coreboot source code and use some form of serial line
"framing" protocol, to emulate multiple virtual serial lines over the
single SBI console.  and rewrite openocd to support it.  and. and.
and. and.

 that's a lairy nightmare waiting to happen, and, on early debug of
real silicon where you're hand-programming the PLL and the serial
port's outputting crap because you've no idea of the baud rate, you
wouldn't see ASCII characters if you got it right, you'd see framing
crap instead and couldn't plug in simple minicom, it'd have to be a
*modified* version of minicom.  etc. etc. etc. etc.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

 naah.  see above.  it's a lot more complex and fragile than that.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Samuel Falvo II]

on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> which is why i'm a bit unhappy to see this (to me) cancerous growth in
> proposals for m- mode code. ppp in firmware? really? multiple serial

i'm inclined to agree with the overall sentiment of the concerns
raised herein (omitted for brevity), but i feel that it might go a bit
too far.

the bios has its roots with cp/m, i think we all can agree with this,
and there the bios was well-matched to its task: booting cp/m.
nothing more, nothing less.

you had i/o routines for teletype output, keyboard input, paper tape
input, and punch output.  as well, you had basic primitives for
reading and writing sectors on mass storage devices.  and, unless you
were porting cp/m itself to a completely new platform, you never had
to *really* worry about the physical constraints of those mass storage
devices.  maximum number of sectors and tracks were about the extent
of things.  you never had to call back into anything, either.

in other words, bios was a *library*, not a *framework.*  it was
*deliberately* designed and scoped to just deal with booting into a
cp/m environment.

originally, the pc bios was built the same way -- it was what you used
to boot pc-dos (nee ms-dos).

only *later* did massive api changes get lumped into the bios.  things
like protected memory support, acpi power mode settings, etc. all but
required changing the bios away from being a library and into more of
a framework/miniature os unto itself.

i think the real lessons to be learned here are:

1) the bios interface was dictated by the demands of booting and
running a preferred (though not the only) os.  in other words, the
*os* dictated the bios interface.  bios literally was what one would
call a "hal" (hardware abstraction layer) these days.  the fact that
others have technically used bios to boot into other, non-sanctioned
oses over the years is, technically, an abuse of the interface that
just happens to work.

2) bios was strictly a library.  the maximum extent to which bios was
a framework stopped firmly at loading in the master boot record and
dispatching control to it.  from then on, you were utterly on your
own.  note: no security hoo-haw here.  no signed anything.  no pe
executables.  no rom-filesystems.  no dedicated uefi partitions.  et.
al.  just read in 512b to 1kb of raw binary blob, and run it.  that's
it.  from then on, bios was a library first and always.  anything we
come up with for an sbi must, in my opinion, behave the same way.

oh, btw, before people get the idea that uefi allows per-partition
filesystems, please note that os/2 used "micro-filesystem drivers" to
achieve this same effect with nothing more sophisticated than the
partition table located in a dos 3.3 mbr.  don't drink the uefi
kool-aid.

3) corrallary to (2): because bios was just a library, you could throw
it away en mass at any time (and after booting into the os of your
choice, it frequently was).  you could, if you were clever enough with
page tables and the like, even replace the bios with your own image if
you wanted to.  this speaks to what ron has discussed in prior threads
over the concerns of not being able to replace m-mode software.

4) support for multiple devices is not necessarily a bad thing; just,
don't go hog wild with it.  there's no need to support 256 possible
serial ports, for example.  ok, you have a debugger interface, a
resident console, and maybe one more for auxiliary purposes (for
example, my kestrel-3 design so far needs *two* serial interfaces to
the host pc, one which is the user's console, and one which is used to
access mass storage).  each of these devices should have their own
read/write interface, thus making it impeccably clear in the source
code what it is you're trying to do.  no need to "open" things.

my point here is, going back to the needs of the *os* and not the bios
for bios' sake, the interface exposed by the bios should match the
overall expectations of the os you're booting.  in my case, i *need*
two serial interfaces for my prototype computer to function: ergo, it
makes perfect sense for my firmware to provide support for two serial
interfaces.  for the linux, this need not be the case; maybe only one
interface is required.

> the sbi should be hard to add to, deliberately. it should be used only
> when there are no possible alternatives. it needs to be open source
> and held in common. it should be possible for a kernel to replace or
> at least measure it. and, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.

i'm reposting this block of test because i agree completely with it,
and want to point out that it doesn't contradict what i wrote above.

> p.s. for interleaving debug and console output firmware, use the
> oldest trick in the book: ascii is 7 bits. since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. it's very easy and doesn't require that we add multiple uart
> support to sbi.

another option is to use escape sequences preceding each output.
escape byte 1 would mean "future bytes are sent to the debugger",
while byte 2 would mean "future bytes are intended for console
output."  this gives you support for all 8-bits (if your debugger
interface happens to be binary), with the occasional overhead of
escaping escape bytes.

trivial to implement both on the receiving and transmitting sides,
possibly even simpler than the bit-7-target-address approach above.
the only disadvantage is that it's stateful; but if you have a serial
connection reliable enough to use with a binary debugging interface,
it'll almost certainly be reliable enough for this too.

-- 
samuel a. falvo ii

Re: [sw-dev] SBI extension proposal v2

[Samuel Falvo II]

on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> which is why i'm a bit unhappy to see this (to me) cancerous growth in
> proposals for m- mode code. ppp in firmware? really? multiple serial

i'm inclined to agree with the overall sentiment of the concerns
raised herein (omitted for brevity), but i feel that it might go a bit
too far.

the bios has its roots with cp/m, i think we all can agree with this,
and there the bios was well-matched to its task: booting cp/m.
nothing more, nothing less.

you had i/o routines for teletype output, keyboard input, paper tape
input, and punch output.  as well, you had basic primitives for
reading and writing sectors on mass storage devices.  and, unless you
were porting cp/m itself to a completely new platform, you never had
to *really* worry about the physical constraints of those mass storage
devices.  maximum number of sectors and tracks were about the extent
of things.  you never had to call back into anything, either.

in other words, bios was a *library*, not a *framework.*  it was
*deliberately* designed and scoped to just deal with booting into a
cp/m environment.

originally, the pc bios was built the same way -- it was what you used
to boot pc-dos (nee ms-dos).

only *later* did massive api changes get lumped into the bios.  things
like protected memory support, acpi power mode settings, etc. all but
required changing the bios away from being a library and into more of
a framework/miniature os unto itself.

i think the real lessons to be learned here are:

1) the bios interface was dictated by the demands of booting and
running a preferred (though not the only) os.  in other words, the
*os* dictated the bios interface.  bios literally was what one would
call a "hal" (hardware abstraction layer) these days.  the fact that
others have technically used bios to boot into other, non-sanctioned
oses over the years is, technically, an abuse of the interface that
just happens to work.

2) bios was strictly a library.  the maximum extent to which bios was
a framework stopped firmly at loading in the master boot record and
dispatching control to it.  from then on, you were utterly on your
own.  note: no security hoo-haw here.  no signed anything.  no pe
executables.  no rom-filesystems.  no dedicated uefi partitions.  et.
al.  just read in 512b to 1kb of raw binary blob, and run it.  that's
it.  from then on, bios was a library first and always.  anything we
come up with for an sbi must, in my opinion, behave the same way.

oh, btw, before people get the idea that uefi allows per-partition
filesystems, please note that os/2 used "micro-filesystem drivers" to
achieve this same effect with nothing more sophisticated than the
partition table located in a dos 3.3 mbr.  don't drink the uefi
kool-aid.

3) corrallary to (2): because bios was just a library, you could throw
it away en mass at any time (and after booting into the os of your
choice, it frequently was).  you could, if you were clever enough with
page tables and the like, even replace the bios with your own image if
you wanted to.  this speaks to what ron has discussed in prior threads
over the concerns of not being able to replace m-mode software.

4) support for multiple devices is not necessarily a bad thing; just,
don't go hog wild with it.  there's no need to support 256 possible
serial ports, for example.  ok, you have a debugger interface, a
resident console, and maybe one more for auxiliary purposes (for
example, my kestrel-3 design so far needs *two* serial interfaces to
the host pc, one which is the user's console, and one which is used to
access mass storage).  each of these devices should have their own
read/write interface, thus making it impeccably clear in the source
code what it is you're trying to do.  no need to "open" things.

my point here is, going back to the needs of the *os* and not the bios
for bios' sake, the interface exposed by the bios should match the
overall expectations of the os you're booting.  in my case, i *need*
two serial interfaces for my prototype computer to function: ergo, it
makes perfect sense for my firmware to provide support for two serial
interfaces.  for the linux, this need not be the case; maybe only one
interface is required.

> the sbi should be hard to add to, deliberately. it should be used only
> when there are no possible alternatives. it needs to be open source
> and held in common. it should be possible for a kernel to replace or
> at least measure it. and, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.

i'm reposting this block of test because i agree completely with it,
and want to point out that it doesn't contradict what i wrote above.

> p.s. for interleaving debug and console output firmware, use the
> oldest trick in the book: ascii is 7 bits. since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. it's very easy and doesn't require that we add multiple uart
> support to sbi.

another option is to use escape sequences preceding each output.
escape byte 1 would mean "future bytes are sent to the debugger",
while byte 2 would mean "future bytes are intended for console
output."  this gives you support for all 8-bits (if your debugger
interface happens to be binary), with the occasional overhead of
escaping escape bytes.

trivial to implement both on the receiving and transmitting sides,
possibly even simpler than the bit-7-target-address approach above.
the only disadvantage is that it's stateful; but if you have a serial
connection reliable enough to use with a binary debugging interface,
it'll almost certainly be reliable enough for this too.

-- 
samuel a. falvo ii

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:39 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> > which is why i'm a bit unhappy to see this (to me) cancerous growth in
> > proposals for m- mode code. ppp in firmware? really? multiple serial
>
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

 it's also not an appropriate argument.  nobody sensible would port a
POSIX pppd from userspace into boot-level firmware.  the argument also
ignores the dozens of other advantageous potential use-cases.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:39 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> on sat, nov 10, 2018 at 8:46 am ron minnich <rminnich@gmail.com> wrote:
> > which is why i'm a bit unhappy to see this (to me) cancerous growth in
> > proposals for m- mode code. ppp in firmware? really? multiple serial
>
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

 it's also not an appropriate argument.  nobody sensible would port a
POSIX pppd from userspace into boot-level firmware.  the argument also
ignores the dozens of other advantageous potential use-cases.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Samuel Falvo II]

On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  it's also not an appropriate argument.  nobody sensible would port a
> POSIX pppd from userspace into boot-level firmware.  the argument also
> ignores the dozens of other advantageous potential use-cases.

Regrettably, if it's one thing we've all learned from PC clone
manufacturers and BIOS vendors, it's that they're not sensible.
They're not reasonable.  And they're anything but sane.

Servers designed for use in data centers are on the market right now
with adapters fully equipped with TCP/IP stacks in firmware *just* to
give a remote operator control over a computer's PS/2 or serial ports,
for instance.

You can bank that it'll happen with RISC-V as well.

-- 
Samuel A. Falvo II

Re: [sw-dev] SBI extension proposal v2

[Samuel Falvo II]

On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  it's also not an appropriate argument.  nobody sensible would port a
> POSIX pppd from userspace into boot-level firmware.  the argument also
> ignores the dozens of other advantageous potential use-cases.

Regrettably, if it's one thing we've all learned from PC clone
manufacturers and BIOS vendors, it's that they're not sensible.
They're not reasonable.  And they're anything but sane.

Servers designed for use in data centers are on the market right now
with adapters fully equipped with TCP/IP stacks in firmware *just* to
give a remote operator control over a computer's PS/2 or serial ports,
for instance.

You can bank that it'll happen with RISC-V as well.

-- 
Samuel A. Falvo II

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:48 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >  it's also not an appropriate argument.  nobody sensible would port a
> > POSIX pppd from userspace into boot-level firmware.  the argument also
> > ignores the dozens of other advantageous potential use-cases.
>
> Regrettably, if it's one thing we've all learned from PC clone
> manufacturers and BIOS vendors, it's that they're not sensible.
> They're not reasonable.  And they're anything but sane.
>
> Servers designed for use in data centers are on the market right now
> with adapters fully equipped with TCP/IP stacks in firmware *just* to
> give a remote operator control over a computer's PS/2 or serial ports,
> for instance.
>
> You can bank that it'll happen with RISC-V as well.

 *snort* yeah.  is that a good enough reason to terminate all and any
discussion of enhancing a general-purpose generic API that has several
other beneficial use-cases?  reminds me of the adage "guns don't kill
people: people kill people".

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:48 PM Samuel Falvo II <sam.falvo@gmail.com> wrote:

> On Sat, Nov 10, 2018 at 9:43 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >  it's also not an appropriate argument.  nobody sensible would port a
> > POSIX pppd from userspace into boot-level firmware.  the argument also
> > ignores the dozens of other advantageous potential use-cases.
>
> Regrettably, if it's one thing we've all learned from PC clone
> manufacturers and BIOS vendors, it's that they're not sensible.
> They're not reasonable.  And they're anything but sane.
>
> Servers designed for use in data centers are on the market right now
> with adapters fully equipped with TCP/IP stacks in firmware *just* to
> give a remote operator control over a computer's PS/2 or serial ports,
> for instance.
>
> You can bank that it'll happen with RISC-V as well.

 *snort* yeah.  is that a good enough reason to terminate all and any
discussion of enhancing a general-purpose generic API that has several
other beneficial use-cases?  reminds me of the adage "guns don't kill
people: people kill people".

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Samuel Falvo II]

On Sat, Nov 10, 2018 at 9:55 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  *snort* yeah.  is that a good enough reason to terminate all and any
> discussion of enhancing a general-purpose generic API that has several
> other beneficial use-cases?  reminds me of the adage "guns don't kill
> people: people kill people".

I think you are misunderstanding what I'm writing.

My tale is one of caution, not prevention.  I'm OK with having a BIOS.
History shows that the problems on the PC platform all started when
the BIOS *disappeared*; when it *stopped* *being* a BIOS.

My claim is that Ron's reaction is, while well-intentioned and has
solid roots in first-hand experience, nonetheless a bit extreme.  Not
having any BIOS at all is, in my estimation, worse than having one
that is 50 years old.

-- 
Samuel A. Falvo II

Re: [sw-dev] SBI extension proposal v2

[Samuel Falvo II]

On Sat, Nov 10, 2018 at 9:55 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>  *snort* yeah.  is that a good enough reason to terminate all and any
> discussion of enhancing a general-purpose generic API that has several
> other beneficial use-cases?  reminds me of the adage "guns don't kill
> people: people kill people".

I think you are misunderstanding what I'm writing.

My tale is one of caution, not prevention.  I'm OK with having a BIOS.
History shows that the problems on the PC platform all started when
the BIOS *disappeared*; when it *stopped* *being* a BIOS.

My claim is that Ron's reaction is, while well-intentioned and has
solid roots in first-hand experience, nonetheless a bit extreme.  Not
having any BIOS at all is, in my estimation, worse than having one
that is 50 years old.

-- 
Samuel A. Falvo II

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Samuel Falvo II]

Sorry for being all lower-case; I composed my text in Vim, and when I
copied it to the clipboard, I must have issued a command that
lowercased everything accidentally.

On Sat, Nov 10, 2018 at 9:41 AM Samuel Falvo II <sam.falvo@gmail.com> wrote:
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

-- 
Samuel A. Falvo II

Re: [sw-dev] SBI extension proposal v2

[Samuel Falvo II]

Sorry for being all lower-case; I composed my text in Vim, and when I
copied it to the clipboard, I must have issued a command that
lowercased everything accidentally.

On Sat, Nov 10, 2018 at 9:41 AM Samuel Falvo II <sam.falvo@gmail.com> wrote:
> i'm inclined to agree with the overall sentiment of the concerns
> raised herein (omitted for brevity), but i feel that it might go a bit
> too far.

-- 
Samuel A. Falvo II

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Olof Johansson]

On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
>
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
>
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
>
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
>
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?

There's a tension between letting people do the messy things that real
hardware sometimes needs without polluting higher layers in the
software stack, and letting them do too much of things that _should_
be handled in the upper layers. I have yet to find a solution that
doesn't need tweaking over time, the pendulum tends to swing back and
forth into "too far" in both directions sometimes.

The case of console is in this case pretty simple: It's intended for
early boot for very simplistic environments (before the rest of the
kernel is up, etc). Keeping the SBI console around beyond early boot,
and somehow trying to optimize for it for those use cases is a
misdirected effort; that's what native drivers are for.

Having to do fine-grained arbitration of device ownership between
firmware and kernel at runtime is usually error prone and awkward and
best to avoid.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

Sure, it helps for 2 channels. And then beyond that you need a more
complex protocol. Either way, it's not a problem we need to solve here
and now.


-Olof

Re: [sw-dev] SBI extension proposal v2

[Olof Johansson]

On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
>
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
>
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
>
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
>
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?

There's a tension between letting people do the messy things that real
hardware sometimes needs without polluting higher layers in the
software stack, and letting them do too much of things that _should_
be handled in the upper layers. I have yet to find a solution that
doesn't need tweaking over time, the pendulum tends to swing back and
forth into "too far" in both directions sometimes.

The case of console is in this case pretty simple: It's intended for
early boot for very simplistic environments (before the rest of the
kernel is up, etc). Keeping the SBI console around beyond early boot,
and somehow trying to optimize for it for those use cases is a
misdirected effort; that's what native drivers are for.

Having to do fine-grained arbitration of device ownership between
firmware and kernel at runtime is usually error prone and awkward and
best to avoid.


> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.

Sure, it helps for 2 channels. And then beyond that you need a more
complex protocol. Either way, it's not a problem we need to solve here
and now.


-Olof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.

 spike (which is only around 7,000 lines of code) doesn't have native
drivers, and qemu is too heavy-duty to consider adding custom
extensions and experimental research onto.

 with nothing in spike *other* than the serial console, it's the only
way in and out.

 l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.

 spike (which is only around 7,000 lines of code) doesn't have native
drivers, and qemu is too heavy-duty to consider adding custom
extensions and experimental research onto.

 with nothing in spike *other* than the serial console, it's the only
way in and out.

 l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
> 
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.
> 
>  l.

Anything more than a main/debug console is too much for the SBI, its
goal is to be used early on in the boot process until the OS or the
bare metal app takes control. Having multiple serial lines through
the SBI for things like PPP, UPS, virtual consoles and all the stuff
you mentioned is out of scope. Boot an OS and use the standard UART
drivers for accessing the serial lines. If there are no drivers
or support on spike, it's open source ! Also you may always use
the vendor specific SBI that Atish proposes here for adding that
functionality, having this on the base SBI is not the right
approach IMHO.

Regards,
Nick

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
> 
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.
> 
>  l.

Anything more than a main/debug console is too much for the SBI, its
goal is to be used early on in the boot process until the OS or the
bare metal app takes control. Having multiple serial lines through
the SBI for things like PPP, UPS, virtual consoles and all the stuff
you mentioned is out of scope. Boot an OS and use the standard UART
drivers for accessing the serial lines. If there are no drivers
or support on spike, it's open source ! Also you may always use
the vendor specific SBI that Atish proposes here for adding that
functionality, having this on the base SBI is not the right
approach IMHO.

Regards,
Nick

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[ron minnich]

Actually, as long as the option remains to let the kernel replace the
SBI with something else, I'm not that worried about what vendors put
in it. But that option needs to remain there.
On Sat, Nov 10, 2018 at 9:59 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control. Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope. Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source ! Also you may always use
> the vendor specific SBI that Atish proposes here for adding that
> functionality, having this on the base SBI is not the right
> approach IMHO.
>
> Regards,
> Nick

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

Actually, as long as the option remains to let the kernel replace the
SBI with something else, I'm not that worried about what vendors put
in it. But that option needs to remain there.
On Sat, Nov 10, 2018 at 9:59 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control. Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope. Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source ! Also you may always use
> the vendor specific SBI that Atish proposes here for adding that
> functionality, having this on the base SBI is not the right
> approach IMHO.
>
> Regards,
> Nick

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 6:02 PM ron minnich <rminnich@gmail.com> wrote:

> Actually, as long as the option remains to let the kernel replace the
> SBI with something else, I'm not that worried about what vendors put
> in it. But that option needs to remain there.

 i remember you saying, when the boot discussion came up a couple
weeks ago, and agree absolutely: the option in real hardware to shut
off and replace whatever's got you up and running is critical.

 there's a huge range of uses to which SBI is (and can be) put: i
threw some ideas out there, i feel it's important to bear that in
mind.  it's not just used for booting, it's also got simulation,
debugging, development and critical first silicon bring-up potential,
out-of-band remote power management potential uses, virtual management
potential, and shed-loads more.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 6:02 PM ron minnich <rminnich@gmail.com> wrote:

> Actually, as long as the option remains to let the kernel replace the
> SBI with something else, I'm not that worried about what vendors put
> in it. But that option needs to remain there.

 i remember you saying, when the boot discussion came up a couple
weeks ago, and agree absolutely: the option in real hardware to shut
off and replace whatever's got you up and running is critical.

 there's a huge range of uses to which SBI is (and can be) put: i
threw some ideas out there, i feel it's important to bear that in
mind.  it's not just used for booting, it's also got simulation,
debugging, development and critical first silicon bring-up potential,
out-of-band remote power management potential uses, virtual management
potential, and shed-loads more.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control.

 nooo, that's just _one_ use to which it's being put.

> Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope.

 why?

> Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source !

 this is a common misconception that "because it's open source anyone
can do what they want".  code costs money.  servers to host code cost
money.  answering the emails where people expect "free" support
because you're hosting the only public version of that server costs
money.

 i'm an ethical libre developer: i can't go footing the bill for other
people to sponge off my efforts all the time, i've had 20 years of
people doing that and i'm f*****g well not putting up with it on this
project.

 so no, mick, sorry, not buying the argument "it's open source".

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >
> >> The case of console is in this case pretty simple: It's intended for
> >> early boot for very simplistic environments (before the rest of the
> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> and somehow trying to optimize for it for those use cases is a
> >> misdirected effort; that's what native drivers are for.
> >
> >  spike (which is only around 7,000 lines of code) doesn't have native
> > drivers, and qemu is too heavy-duty to consider adding custom
> > extensions and experimental research onto.
> >
> >  with nothing in spike *other* than the serial console, it's the only
> > way in and out.
> >
> >  l.
>
> Anything more than a main/debug console is too much for the SBI, its
> goal is to be used early on in the boot process until the OS or the
> bare metal app takes control.

 nooo, that's just _one_ use to which it's being put.

> Having multiple serial lines through
> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> you mentioned is out of scope.

 why?

> Boot an OS and use the standard UART
> drivers for accessing the serial lines. If there are no drivers
> or support on spike, it's open source !

 this is a common misconception that "because it's open source anyone
can do what they want".  code costs money.  servers to host code cost
money.  answering the emails where people expect "free" support
because you're hosting the only public version of that server costs
money.

 i'm an ethical libre developer: i can't go footing the bill for other
people to sponge off my efforts all the time, i've had 20 years of
people doing that and i'm f*****g well not putting up with it on this
project.

 so no, mick, sorry, not buying the argument "it's open source".

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
>> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >
>> >> The case of console is in this case pretty simple: It's intended for
>> >> early boot for very simplistic environments (before the rest of the
>> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> and somehow trying to optimize for it for those use cases is a
>> >> misdirected effort; that's what native drivers are for.
>> >
>> >  spike (which is only around 7,000 lines of code) doesn't have native
>> > drivers, and qemu is too heavy-duty to consider adding custom
>> > extensions and experimental research onto.
>> >
>> >  with nothing in spike *other* than the serial console, it's the only
>> > way in and out.
>> >
>> >  l.
>> 
>> Anything more than a main/debug console is too much for the SBI, its
>> goal is to be used early on in the boot process until the OS or the
>> bare metal app takes control.
> 
>  nooo, that's just _one_ use to which it's being put.
> 
>> Having multiple serial lines through
>> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> you mentioned is out of scope.
> 
>  why?
> 

Because the firmware is meant to be something minimal, not to replace 
the
OS. Let me ask you this, if you want to change UART speed or settings in
general would you also ask for an SBI call for that ? What's coming up
next ? Adding networking support for example ? Where do you put the 
barrier
on firmware's complexity / scope ?

>> Boot an OS and use the standard UART
>> drivers for accessing the serial lines. If there are no drivers
>> or support on spike, it's open source !
> 
>  this is a common misconception that "because it's open source anyone
> can do what they want".  code costs money.  servers to host code cost
> money.  answering the emails where people expect "free" support
> because you're hosting the only public version of that server costs
> money.
> 

Even if we decide that the SBI gets extended for accessing different
serial lines, someone will have to write code for that e.g. on BBL or on
OpenSBI, coreboot etc. If we follow your logic, maintaining, hosting
and supporting this also costs money. So what's the point here ? That
it's easier to implement it there for everyone than write a UART driver
for spike ?

By the way spike is an ISA simulator, I don't see why it should emulate
UART ports, last time I checked it didn't, so someone will need to write
code for that, more money ! You can use QEMU for that where you can have
as many UARTs as you want and the drivers for them are already available
for you.

>  i'm an ethical libre developer: i can't go footing the bill for other
> people to sponge off my efforts all the time, i've had 20 years of
> people doing that and i'm f*****g well not putting up with it on this
> project.
> 
>  so no, mick, sorry, not buying the argument "it's open source".
> 
> l.

Don't assume you are the only one.

Regards,
Nick

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
>> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >
>> >> The case of console is in this case pretty simple: It's intended for
>> >> early boot for very simplistic environments (before the rest of the
>> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> and somehow trying to optimize for it for those use cases is a
>> >> misdirected effort; that's what native drivers are for.
>> >
>> >  spike (which is only around 7,000 lines of code) doesn't have native
>> > drivers, and qemu is too heavy-duty to consider adding custom
>> > extensions and experimental research onto.
>> >
>> >  with nothing in spike *other* than the serial console, it's the only
>> > way in and out.
>> >
>> >  l.
>> 
>> Anything more than a main/debug console is too much for the SBI, its
>> goal is to be used early on in the boot process until the OS or the
>> bare metal app takes control.
> 
>  nooo, that's just _one_ use to which it's being put.
> 
>> Having multiple serial lines through
>> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> you mentioned is out of scope.
> 
>  why?
> 

Because the firmware is meant to be something minimal, not to replace 
the
OS. Let me ask you this, if you want to change UART speed or settings in
general would you also ask for an SBI call for that ? What's coming up
next ? Adding networking support for example ? Where do you put the 
barrier
on firmware's complexity / scope ?

>> Boot an OS and use the standard UART
>> drivers for accessing the serial lines. If there are no drivers
>> or support on spike, it's open source !
> 
>  this is a common misconception that "because it's open source anyone
> can do what they want".  code costs money.  servers to host code cost
> money.  answering the emails where people expect "free" support
> because you're hosting the only public version of that server costs
> money.
> 

Even if we decide that the SBI gets extended for accessing different
serial lines, someone will have to write code for that e.g. on BBL or on
OpenSBI, coreboot etc. If we follow your logic, maintaining, hosting
and supporting this also costs money. So what's the point here ? That
it's easier to implement it there for everyone than write a UART driver
for spike ?

By the way spike is an ISA simulator, I don't see why it should emulate
UART ports, last time I checked it didn't, so someone will need to write
code for that, more money ! You can use QEMU for that where you can have
as many UARTs as you want and the drivers for them are already available
for you.

>  i'm an ethical libre developer: i can't go footing the bill for other
> people to sponge off my efforts all the time, i've had 20 years of
> people doing that and i'm f*****g well not putting up with it on this
> project.
> 
>  so no, mick, sorry, not buying the argument "it's open source".
> 
> l.

Don't assume you are the only one.

Regards,
Nick


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> ???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
> > wrote:
> >>
> >> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >> >
> >> >> The case of console is in this case pretty simple: It's intended for
> >> >> early boot for very simplistic environments (before the rest of the
> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> >> and somehow trying to optimize for it for those use cases is a
> >> >> misdirected effort; that's what native drivers are for.
> >> >
> >> >  spike (which is only around 7,000 lines of code) doesn't have native
> >> > drivers, and qemu is too heavy-duty to consider adding custom
> >> > extensions and experimental research onto.
> >> >
> >> >  with nothing in spike *other* than the serial console, it's the only
> >> > way in and out.
> >> >
> >> >  l.
> >>
> >> Anything more than a main/debug console is too much for the SBI, its
> >> goal is to be used early on in the boot process until the OS or the
> >> bare metal app takes control.
> >
> >  nooo, that's just _one_ use to which it's being put.
> >
> >> Having multiple serial lines through
> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> >> you mentioned is out of scope.
> >
> >  why?
> >
>
> Because the firmware is meant to be something minimal, not to replace
> the
> OS. Let me ask you this, if you want to change UART speed or settings in
> general would you also ask for an SBI call for that ?

 of course, not, nick.  it's a simple cut/paste of the existing
console getchar/putchar code.  you're beginning to alarm me by making
this out to be much more complex than it is.

 if i'd thought it was a good idea to propose an SBI call to change
UART speed or settings, i would have said so.  there's absolutely no
need to make it *look* like i've proposed that.  doing so - putting
words into someone else's mouth - is unethical, and i'd appreciate it
if you could stop doing it.


> What's coming up next ?

 nothing, nick.  just one extra parameter to the console
getchar/putchar function [or a duplicate function which does] that's
all.

> Adding networking support for example ?

 of course not.  why on earth would that make sense?  how on earth
would networking fit into a 16k Boot ROM?

 i feel that you're arguing and throwing up straw-man questions for
arguments' sake, here, hoping that one of them will stick, and that by
ignoring the positive aspects of the (incredibly simple)
cut/paste-style minimalist proposal and throwing as many "bad" ones
out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
questions you're asking?


> Where do you put the
> barrier
> on firmware's complexity / scope ?

 at the exact same point that you do, under the circumstances and
context in which you're looking at and from.

 now, can you recognise that there are *other* needs and requirements
as well, beyond the ones that you have?

> By the way spike is an ISA simulator, I don't see why it should emulate
> UART ports, last time I checked it didn't,

 ah, nick, i get the feeling you're deliberately looking for ways to
be obstructive, and also fundamentally misunderstanding how the
getchar / putchar code works.

 spike provides a minimal implementation of the SBI, via libfesvr.
the data that goes to the getchar/putchar function is ultimately
redirected to a minimalist stdin / stdout implementation.  there *is*
no call to UART ports.

 come on, man, be a little less adversarial: it makes life easier for everyone.


> so someone will need to write
> code for that, more money !

 i'll happily do it, as i need it.  it's a straight cut/paste of
pre-existing code.

> You can use QEMU for that where you can have
> as many UARTs as you want and the drivers for them are already available
> for you.

 i *can't*.  qemu is too complex and i've invested 2 months of
personal money - without funding or grants from any corporation or
institution - into spike, precisely because it's only 7,000 lines of
code.

 modifying qemu is too much.  i've seen signs that they're moving into
JIT optimisation territory, which is far too complex to get involved
with.

spike is simple, it's straightforward, it's fast, and it works.


> >  i'm an ethical libre developer: i can't go footing the bill for other
> > people to sponge off my efforts all the time, i've had 20 years of
> > people doing that and i'm f*****g well not putting up with it on this
> > project.
> >
> >  so no, mick, sorry, not buying the argument "it's open source".
> >
> > l.
>
> Don't assume you are the only one.

 good to hear.

now... can i ask you if you could possibly turn down the adversarial
straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
effort on your part to maintain, and makes it really really difficult
for everyone to have to read, "no, that's not right, no, that's not
true either, no, i didn't say that at all" and so on.

what do you think?


l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
> > wrote:
> >>
> >> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
> >> >
> >> >> The case of console is in this case pretty simple: It's intended for
> >> >> early boot for very simplistic environments (before the rest of the
> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
> >> >> and somehow trying to optimize for it for those use cases is a
> >> >> misdirected effort; that's what native drivers are for.
> >> >
> >> >  spike (which is only around 7,000 lines of code) doesn't have native
> >> > drivers, and qemu is too heavy-duty to consider adding custom
> >> > extensions and experimental research onto.
> >> >
> >> >  with nothing in spike *other* than the serial console, it's the only
> >> > way in and out.
> >> >
> >> >  l.
> >>
> >> Anything more than a main/debug console is too much for the SBI, its
> >> goal is to be used early on in the boot process until the OS or the
> >> bare metal app takes control.
> >
> >  nooo, that's just _one_ use to which it's being put.
> >
> >> Having multiple serial lines through
> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
> >> you mentioned is out of scope.
> >
> >  why?
> >
>
> Because the firmware is meant to be something minimal, not to replace
> the
> OS. Let me ask you this, if you want to change UART speed or settings in
> general would you also ask for an SBI call for that ?

 of course, not, nick.  it's a simple cut/paste of the existing
console getchar/putchar code.  you're beginning to alarm me by making
this out to be much more complex than it is.

 if i'd thought it was a good idea to propose an SBI call to change
UART speed or settings, i would have said so.  there's absolutely no
need to make it *look* like i've proposed that.  doing so - putting
words into someone else's mouth - is unethical, and i'd appreciate it
if you could stop doing it.


> What's coming up next ?

 nothing, nick.  just one extra parameter to the console
getchar/putchar function [or a duplicate function which does] that's
all.

> Adding networking support for example ?

 of course not.  why on earth would that make sense?  how on earth
would networking fit into a 16k Boot ROM?

 i feel that you're arguing and throwing up straw-man questions for
arguments' sake, here, hoping that one of them will stick, and that by
ignoring the positive aspects of the (incredibly simple)
cut/paste-style minimalist proposal and throwing as many "bad" ones
out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
questions you're asking?


> Where do you put the
> barrier
> on firmware's complexity / scope ?

 at the exact same point that you do, under the circumstances and
context in which you're looking at and from.

 now, can you recognise that there are *other* needs and requirements
as well, beyond the ones that you have?

> By the way spike is an ISA simulator, I don't see why it should emulate
> UART ports, last time I checked it didn't,

 ah, nick, i get the feeling you're deliberately looking for ways to
be obstructive, and also fundamentally misunderstanding how the
getchar / putchar code works.

 spike provides a minimal implementation of the SBI, via libfesvr.
the data that goes to the getchar/putchar function is ultimately
redirected to a minimalist stdin / stdout implementation.  there *is*
no call to UART ports.

 come on, man, be a little less adversarial: it makes life easier for everyone.


> so someone will need to write
> code for that, more money !

 i'll happily do it, as i need it.  it's a straight cut/paste of
pre-existing code.

> You can use QEMU for that where you can have
> as many UARTs as you want and the drivers for them are already available
> for you.

 i *can't*.  qemu is too complex and i've invested 2 months of
personal money - without funding or grants from any corporation or
institution - into spike, precisely because it's only 7,000 lines of
code.

 modifying qemu is too much.  i've seen signs that they're moving into
JIT optimisation territory, which is far too complex to get involved
with.

spike is simple, it's straightforward, it's fast, and it works.


> >  i'm an ethical libre developer: i can't go footing the bill for other
> > people to sponge off my efforts all the time, i've had 20 years of
> > people doing that and i'm f*****g well not putting up with it on this
> > project.
> >
> >  so no, mick, sorry, not buying the argument "it's open source".
> >
> > l.
>
> Don't assume you are the only one.

 good to hear.

now... can i ask you if you could possibly turn down the adversarial
straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
effort on your part to maintain, and makes it really really difficult
for everyone to have to read, "no, that's not right, no, that's not
true either, no, i didn't say that at all" and so on.

what do you think?


l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-11 09:14, Luke Kenneth Casson Leighton ??????:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> ???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>> 
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings 
>> in
>> general would you also ask for an SBI call for that ?
> 
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
> 
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
> 
> 

Sorry that wasn't my intention, my intention was to understand what you
want to achieve. On the one hand you mentioned that you want an SBI
API change so that you can better work with spike, on the other hand
in order to convince the rest of us that this is a good approach for
the SBI API, you mentioned some examples that to me look like
overengineering at this point. I would never e.g. use getchar/putchar 
for
example for PPP etc. On another example you mentioned using this serial
line for providing networking with spike. My questions are honest, I'm
not trying to put words on your mouth.

>> What's coming up next ?
> 
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
> 

ACK and as I told you on my first reply, my only concern there is that
this argument shouldn't be about serial line indices but about "types"
so that (since this thing is going to end up on actual hardware) vendors
don't mess up. If you say serial line 0 for example and your code 
assumes
this is the main console, another vendor might put the debug console 
there
or an auxiliary console. By using a console id instead of a serial line
index, you can hide this on the firmware and deal with it there.

>> Adding networking support for example ?
> 
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
> 

I don't know, why on earth should a 16k Boot ROM be used for accessing
multiple serial lines for PPP, UPS etc ? To me that's the work of an OS,
the same OS that will handle the running of PPP/UPS monitor/whatever.
If you use such examples you should expect that people will assume the
worst (I'm not the only one that assumed the worst btw), and that's what
any reviewer should do.

>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
> 

The positive aspects of supporting multiple serial lines through the SBI
getchar/putchar code that you mention are not clear to me, that's why 
I'm
asking what's the purpose of this other than a hack to get around
limitations on spike. Supporting PPP for example without being able
to set serial parameters is a hack and we shouldn't be discussing that
in the context of the SBI.

>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
> 
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
> 
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
> 

I can understand changing the current SBI and adding an extra argument 
to
chose between a main and a debug console (not by serial line index as I
mentioned above but through a console id argument). Could you please 
help
me understand why you want support for more ports than that on the base 
SBI ?

You mentioned the following...

> * boot message separation from console login

ACK I agree on that, that's what the debug uart can be used for, lots
of people are doing that. However if by boot messages you mean anything
other than dmesg output, you need syslog for that and a /dev/tty* entry
for the debug (or any other) console. To me providing this through a 
driver
that's just a wrapper around the SBI and provides only a small subset of
what a tty driver should provide is fundamentally wrong.

That's why I believe the SBI should only be used for earlyprintk and in
general for things before the OS boots. Once the OS boots we should
have proper UART support.

> * boot management separation from other purposes (u-boot/coreboot)

That makes more sense, at least in this case everything is built-in
on u-boot/coreboot so using a different way of accessing the
main and the debug console shouldn't be a big deal. However I still
don't see any value here for more consoles than main/debug.

> * virtual /dev/ttyS0-3
> * clean UPS reporting and management
> * remote virtual machine power management (power-on / off)
> * simple bog-standard multiple virtual login consoles

To me this is way off, we have networking for that, why on earth should
anyone use serial ports ?

> * separation of debug messages (stdout/stderr) to ease debugging and
> development
> * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
> * PPP serial links.

So again you'll need /dev/tty* for that, which should be handled by
a proper UART driver. Especially for the PPP, unless all you want to
do is hack your way through.

>> By the way spike is an ISA simulator, I don't see why it should 
>> emulate
>> UART ports, last time I checked it didn't,
> 
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
> 
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
> 

So as I said spike doesn't emulate UART ports, and it shouldn't, it's an
ISA simulator, it doesn't and shouldn't emulate devices.

>  come on, man, be a little less adversarial: it makes life easier for 
> everyone.
> 
> 
>> so someone will need to write
>> code for that, more money !
> 
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
> 

So what's the issue ? You can patch spike and add your custom SBI calls
(vendor-specific) on libfesvr and you are done with it. Why should this
extension about multiple serial lines, so that you can do your hacks 
when
testing on spike, should be on the base SBI ?

>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already 
>> available
>> for you.
> 
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
> 
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
> 
> spike is simple, it's straightforward, it's fast, and it works.
> 
> 

What are you trying to do ? Test a specific piece of code / ISA 
extension
etc or emulate a full blown system ? If you just want networking support
on spike let's talk about this instead, that's not an issue regarding 
the
SBI.

>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>> 
>> Don't assume you are the only one.
> 
>  good to hear.
> 
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
> 
> what do you think?
> 
> 
> l.

I think that on a technical discussion labeling your peers as 
"obstructive"
and "adversarial" and bringing non-technical arguments like funding 
issues
etc and how ethical/libre developer you are to the table is not 
appropriate.
I never judged your intentions or characterized you in any way, I'd 
expect
from you to do the same.

Regards,
Nick

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-11 09:14, Luke Kenneth Casson Leighton έγραψε:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>> 
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings 
>> in
>> general would you also ask for an SBI call for that ?
> 
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
> 
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
> 
> 

Sorry that wasn't my intention, my intention was to understand what you
want to achieve. On the one hand you mentioned that you want an SBI
API change so that you can better work with spike, on the other hand
in order to convince the rest of us that this is a good approach for
the SBI API, you mentioned some examples that to me look like
overengineering at this point. I would never e.g. use getchar/putchar 
for
example for PPP etc. On another example you mentioned using this serial
line for providing networking with spike. My questions are honest, I'm
not trying to put words on your mouth.

>> What's coming up next ?
> 
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
> 

ACK and as I told you on my first reply, my only concern there is that
this argument shouldn't be about serial line indices but about "types"
so that (since this thing is going to end up on actual hardware) vendors
don't mess up. If you say serial line 0 for example and your code 
assumes
this is the main console, another vendor might put the debug console 
there
or an auxiliary console. By using a console id instead of a serial line
index, you can hide this on the firmware and deal with it there.

>> Adding networking support for example ?
> 
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
> 

I don't know, why on earth should a 16k Boot ROM be used for accessing
multiple serial lines for PPP, UPS etc ? To me that's the work of an OS,
the same OS that will handle the running of PPP/UPS monitor/whatever.
If you use such examples you should expect that people will assume the
worst (I'm not the only one that assumed the worst btw), and that's what
any reviewer should do.

>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
> 

The positive aspects of supporting multiple serial lines through the SBI
getchar/putchar code that you mention are not clear to me, that's why 
I'm
asking what's the purpose of this other than a hack to get around
limitations on spike. Supporting PPP for example without being able
to set serial parameters is a hack and we shouldn't be discussing that
in the context of the SBI.

>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
> 
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
> 
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
> 

I can understand changing the current SBI and adding an extra argument 
to
chose between a main and a debug console (not by serial line index as I
mentioned above but through a console id argument). Could you please 
help
me understand why you want support for more ports than that on the base 
SBI ?

You mentioned the following...

> * boot message separation from console login

ACK I agree on that, that's what the debug uart can be used for, lots
of people are doing that. However if by boot messages you mean anything
other than dmesg output, you need syslog for that and a /dev/tty* entry
for the debug (or any other) console. To me providing this through a 
driver
that's just a wrapper around the SBI and provides only a small subset of
what a tty driver should provide is fundamentally wrong.

That's why I believe the SBI should only be used for earlyprintk and in
general for things before the OS boots. Once the OS boots we should
have proper UART support.

> * boot management separation from other purposes (u-boot/coreboot)

That makes more sense, at least in this case everything is built-in
on u-boot/coreboot so using a different way of accessing the
main and the debug console shouldn't be a big deal. However I still
don't see any value here for more consoles than main/debug.

> * virtual /dev/ttyS0-3
> * clean UPS reporting and management
> * remote virtual machine power management (power-on / off)
> * simple bog-standard multiple virtual login consoles

To me this is way off, we have networking for that, why on earth should
anyone use serial ports ?

> * separation of debug messages (stdout/stderr) to ease debugging and
> development
> * remote and virtual OpenOCD and kernel debugging without disrupting
> the main serial console
> * PPP serial links.

So again you'll need /dev/tty* for that, which should be handled by
a proper UART driver. Especially for the PPP, unless all you want to
do is hack your way through.

>> By the way spike is an ISA simulator, I don't see why it should 
>> emulate
>> UART ports, last time I checked it didn't,
> 
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
> 
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
> 

So as I said spike doesn't emulate UART ports, and it shouldn't, it's an
ISA simulator, it doesn't and shouldn't emulate devices.

>  come on, man, be a little less adversarial: it makes life easier for 
> everyone.
> 
> 
>> so someone will need to write
>> code for that, more money !
> 
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
> 

So what's the issue ? You can patch spike and add your custom SBI calls
(vendor-specific) on libfesvr and you are done with it. Why should this
extension about multiple serial lines, so that you can do your hacks 
when
testing on spike, should be on the base SBI ?

>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already 
>> available
>> for you.
> 
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
> 
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
> 
> spike is simple, it's straightforward, it's fast, and it works.
> 
> 

What are you trying to do ? Test a specific piece of code / ISA 
extension
etc or emulate a full blown system ? If you just want networking support
on spike let's talk about this instead, that's not an issue regarding 
the
SBI.

>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>> 
>> Don't assume you are the only one.
> 
>  good to hear.
> 
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
> 
> what do you think?
> 
> 
> l.

I think that on a technical discussion labeling your peers as 
"obstructive"
and "adversarial" and bringing non-technical arguments like funding 
issues
etc and how ethical/libre developer you are to the table is not 
appropriate.
I never judged your intentions or characterized you in any way, I'd 
expect
from you to do the same.

Regards,
Nick

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Palmer Dabbelt]

On Sat, 10 Nov 2018 23:14:40 PST (-0800), lkcl at lkcl.net wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>
>> ???? 2018-11-10 21:39, Luke Kenneth Casson Leighton ??????:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> ???? 2018-11-10 19:47, Luke Kenneth Casson Leighton ??????:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>>
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings in
>> general would you also ask for an SBI call for that ?
>
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
>
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
>
>
>> What's coming up next ?
>
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
>
>> Adding networking support for example ?
>
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
>
>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
>
>
>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
>
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
>
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
>
>> By the way spike is an ISA simulator, I don't see why it should emulate
>> UART ports, last time I checked it didn't,
>
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
>
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
>
>  come on, man, be a little less adversarial: it makes life easier for everyone.
>
>
>> so someone will need to write
>> code for that, more money !
>
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
>
>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already available
>> for you.
>
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
>
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
>
> spike is simple, it's straightforward, it's fast, and it works.
>
>
>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>>
>> Don't assume you are the only one.
>
>  good to hear.
>
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
>
> what do you think?

Luke: You may be used to posting on the sw-dev and isa-dev mailing lists where 
this kind of post appears to be acceptable.  In case you didn't notice, you've 
now managed to get linux-riscv on your CC list.  I've already dropped all the 
@riscv.org lists from my inbox because they're worthless, but work actually 
happens on linux-riscv and I'd like it to continue being useful.

Please keep the noise down.

Thanks!

Re: [sw-dev] SBI extension proposal v2

[Palmer Dabbelt]

On Sat, 10 Nov 2018 23:14:40 PST (-0800), lkcl@lkcl.net wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Sun, Nov 11, 2018 at 3:15 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>
>> Στις 2018-11-10 21:39, Luke Kenneth Casson Leighton έγραψε:
>> > ---
>> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>> >
>> > On Sat, Nov 10, 2018 at 5:59 PM Nick Kossifidis <mick@ics.forth.gr>
>> > wrote:
>> >>
>> >> Στις 2018-11-10 19:47, Luke Kenneth Casson Leighton έγραψε:
>> >> > On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> >> >
>> >> >> The case of console is in this case pretty simple: It's intended for
>> >> >> early boot for very simplistic environments (before the rest of the
>> >> >> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> >> >> and somehow trying to optimize for it for those use cases is a
>> >> >> misdirected effort; that's what native drivers are for.
>> >> >
>> >> >  spike (which is only around 7,000 lines of code) doesn't have native
>> >> > drivers, and qemu is too heavy-duty to consider adding custom
>> >> > extensions and experimental research onto.
>> >> >
>> >> >  with nothing in spike *other* than the serial console, it's the only
>> >> > way in and out.
>> >> >
>> >> >  l.
>> >>
>> >> Anything more than a main/debug console is too much for the SBI, its
>> >> goal is to be used early on in the boot process until the OS or the
>> >> bare metal app takes control.
>> >
>> >  nooo, that's just _one_ use to which it's being put.
>> >
>> >> Having multiple serial lines through
>> >> the SBI for things like PPP, UPS, virtual consoles and all the stuff
>> >> you mentioned is out of scope.
>> >
>> >  why?
>> >
>>
>> Because the firmware is meant to be something minimal, not to replace
>> the
>> OS. Let me ask you this, if you want to change UART speed or settings in
>> general would you also ask for an SBI call for that ?
>
>  of course, not, nick.  it's a simple cut/paste of the existing
> console getchar/putchar code.  you're beginning to alarm me by making
> this out to be much more complex than it is.
>
>  if i'd thought it was a good idea to propose an SBI call to change
> UART speed or settings, i would have said so.  there's absolutely no
> need to make it *look* like i've proposed that.  doing so - putting
> words into someone else's mouth - is unethical, and i'd appreciate it
> if you could stop doing it.
>
>
>> What's coming up next ?
>
>  nothing, nick.  just one extra parameter to the console
> getchar/putchar function [or a duplicate function which does] that's
> all.
>
>> Adding networking support for example ?
>
>  of course not.  why on earth would that make sense?  how on earth
> would networking fit into a 16k Boot ROM?
>
>  i feel that you're arguing and throwing up straw-man questions for
> arguments' sake, here, hoping that one of them will stick, and that by
> ignoring the positive aspects of the (incredibly simple)
> cut/paste-style minimalist proposal and throwing as many "bad" ones
> out there, it'll somehow.. do.. i dunno, what *is* the purpose of the
> questions you're asking?
>
>
>> Where do you put the
>> barrier
>> on firmware's complexity / scope ?
>
>  at the exact same point that you do, under the circumstances and
> context in which you're looking at and from.
>
>  now, can you recognise that there are *other* needs and requirements
> as well, beyond the ones that you have?
>
>> By the way spike is an ISA simulator, I don't see why it should emulate
>> UART ports, last time I checked it didn't,
>
>  ah, nick, i get the feeling you're deliberately looking for ways to
> be obstructive, and also fundamentally misunderstanding how the
> getchar / putchar code works.
>
>  spike provides a minimal implementation of the SBI, via libfesvr.
> the data that goes to the getchar/putchar function is ultimately
> redirected to a minimalist stdin / stdout implementation.  there *is*
> no call to UART ports.
>
>  come on, man, be a little less adversarial: it makes life easier for everyone.
>
>
>> so someone will need to write
>> code for that, more money !
>
>  i'll happily do it, as i need it.  it's a straight cut/paste of
> pre-existing code.
>
>> You can use QEMU for that where you can have
>> as many UARTs as you want and the drivers for them are already available
>> for you.
>
>  i *can't*.  qemu is too complex and i've invested 2 months of
> personal money - without funding or grants from any corporation or
> institution - into spike, precisely because it's only 7,000 lines of
> code.
>
>  modifying qemu is too much.  i've seen signs that they're moving into
> JIT optimisation territory, which is far too complex to get involved
> with.
>
> spike is simple, it's straightforward, it's fast, and it works.
>
>
>> >  i'm an ethical libre developer: i can't go footing the bill for other
>> > people to sponge off my efforts all the time, i've had 20 years of
>> > people doing that and i'm f*****g well not putting up with it on this
>> > project.
>> >
>> >  so no, mick, sorry, not buying the argument "it's open source".
>> >
>> > l.
>>
>> Don't assume you are the only one.
>
>  good to hear.
>
> now... can i ask you if you could possibly turn down the adversarial
> straw-man thing just a leeeetle tiny bit?  it takes a huge amount of
> effort on your part to maintain, and makes it really really difficult
> for everyone to have to read, "no, that's not right, no, that's not
> true either, no, i didn't say that at all" and so on.
>
> what do you think?

Luke: You may be used to posting on the sw-dev and isa-dev mailing lists where 
this kind of post appears to be acceptable.  In case you didn't notice, you've 
now managed to get linux-riscv on your CC list.  I've already dropped all the 
@riscv.org lists from my inbox because they're worthless, but work actually 
happens on linux-riscv and I'd like it to continue being useful.

Please keep the noise down.

Thanks!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Olof Johansson]

On Sat, Nov 10, 2018 at 9:47 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>
> > The case of console is in this case pretty simple: It's intended for
> > early boot for very simplistic environments (before the rest of the
> > kernel is up, etc). Keeping the SBI console around beyond early boot,
> > and somehow trying to optimize for it for those use cases is a
> > misdirected effort; that's what native drivers are for.
>
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
>
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.

I'll repeat myself:

"trying to optimize for those use cases is a misdirected effort".
Trying to optimize your experience on spike at the cost of simplicity
for everybody else is the wrong thing to do.


-Olof

Re: [sw-dev] SBI extension proposal v2

[Olof Johansson]

On Sat, Nov 10, 2018 at 9:47 AM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>
> > The case of console is in this case pretty simple: It's intended for
> > early boot for very simplistic environments (before the rest of the
> > kernel is up, etc). Keeping the SBI console around beyond early boot,
> > and somehow trying to optimize for it for those use cases is a
> > misdirected effort; that's what native drivers are for.
>
>  spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.
>
>  with nothing in spike *other* than the serial console, it's the only
> way in and out.

I'll repeat myself:

"trying to optimize for those use cases is a misdirected effort".
Trying to optimize your experience on spike at the cost of simplicity
for everybody else is the wrong thing to do.


-Olof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 6:03 PM Olof Johansson <olof@lixom.net> wrote:

> "trying to optimize for those use cases is a misdirected effort".
> Trying to optimize your experience on spike at the cost of simplicity
> for everybody else is the wrong thing to do.

 i hear you on why you believe it's an optimisation: i get it, it's a
public API.  that's why i put out a shed-load of other potential
use-cases.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Nov 10, 2018 at 6:03 PM Olof Johansson <olof@lixom.net> wrote:

> "trying to optimize for those use cases is a misdirected effort".
> Trying to optimize your experience on spike at the cost of simplicity
> for everybody else is the wrong thing to do.

 i hear you on why you believe it's an optimisation: i get it, it's a
public API.  that's why i put out a shed-load of other potential
use-cases.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Michael Clark]

>> On 11/11/2018, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>> 
>> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
> spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.

Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.

We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V ?virt? machine that is currently in QEMU.

That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.

> with nothing in spike *other* than the serial console, it's the only
> way in and out.

That?s likely to change.

There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).

Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.

A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It?s a simple boot console.

Apologies Luke, this is not directed at you, rather it is directed at SBI.

I think we should seriously question any interface we add to SBI.

- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can?t or shouldn?t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.

- SBI shouldn?t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don?t yet have hardware for. It?s equally possible that we can make bad software interfaces.

There are some points up for discussion regards HALs.

There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.

We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don?t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.

I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.

Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he?d like to see... possibly not an in-kernel byte-code interpreter...


BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.

Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.

Re: [sw-dev] SBI extension proposal v2

[Michael Clark]

>> On 11/11/2018, at 6:47 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>> 
>> On Sat, Nov 10, 2018 at 5:42 PM Olof Johansson <olof@lixom.net> wrote:
>> 
>> The case of console is in this case pretty simple: It's intended for
>> early boot for very simplistic environments (before the rest of the
>> kernel is up, etc). Keeping the SBI console around beyond early boot,
>> and somehow trying to optimize for it for those use cases is a
>> misdirected effort; that's what native drivers are for.
> 
> spike (which is only around 7,000 lines of code) doesn't have native
> drivers, and qemu is too heavy-duty to consider adding custom
> extensions and experimental research onto.

Neither of those statements are completely true. Spike can have its hardware emulation capabilities expanded and QEMU is not unsuitable for experimental research. For example, we have been developing the CLIC interrupt controller model in QEMU.

We also could port VirtIO from RISCVEMU to spike. It would be nice to add the PLIC, CLIC and an NS16550A UART to spike so we can model the RISC-V “virt” machine that is currently in QEMU.

That said, you are probably correct. A simulator like spike makes a little more sense for evolving the hardware models versus a heavy-weight fast-model emulator like QEMU.

> with nothing in spike *other* than the serial console, it's the only
> way in and out.

That’s likely to change.

There is bare metal code in BBL to support several console types (HTIF, SiFive UART, NS16550A). All of these except for HTIF have kernel device drivers. The main reason for the SBI console is to be used as a bring-up console before full device drivers have been developed and for simulation use-cases (running Linux in spike and HDL simulators).

Spike currently relies on HTIF for console and HTIF is not appropriate as a kernel device interface. HTIF is designed for tethered simulation as it relies on a front-end finding special ELF symbols used for host <-> target communications.

A polled-mode console interface is fine for debug but not appropriate for running something like pppd. Adding a tty layer (sbi_ioctl) to SBI is not a good idea. Note: an actual serial interface has several out-of-band interface to check link status and set baud rates, etc (as do the simple SBI drivers which have these details hardcoded). It’s a simple boot console.

Apologies Luke, this is not directed at you, rather it is directed at SBI.

I think we should seriously question any interface we add to SBI.

- Making SBI a library API is an invitation for binary blobs. It should remain an ECALL interface to fill in privilege boundary virtualization gaps i.e. functions that require M-mode privileges. It can’t or shouldn’t do this if it is linked to the kernel as a library. In the case it were a library the question is why not just document the hardware interface and add a driver to the kernel. For anything else, such as for virtualization; we should minimize address space footprint for anything that is not a device. Otherwise we should spend effort on defining standard hardware interfaces such as virtualizable interrupt controllers or PMUs.

- SBI shouldn’t be used as a wrapper to hide (as yet unspecified) hardware interfaces from the kernel. i.e. for example to hide a device aperture that contains configuration for both M-mode and S-mode interrupts or an interface for a function that we don’t yet have hardware for. It’s equally possible that we can make bad software interfaces.

There are some points up for discussion regards HALs.

There is a principle that functions that have typically been done in hardware can be simplified if certain aspects are devolved to software. This is valid.

We have this with S-mode timer and software interrupts which presently are delegated by the monitor who implements the SBI interface to configure or initiate them. This is not strictly because we don’t want to expose the hardware to Linux i.e. why not just write a driver in Linux? SBI is required here because these functions were initially only able to be executed in M-mode and it would violate a privilege boundary for Linux to run their code as Linux is a Supervisor. i.e. there was no direct interface for S-mode to configure or initiate software or timer interrupts.

I think the best approach is for folk to share their hardware interfaces and explore approaches that allow S-mode to operate autonomously whether M-mode exists or not. I.e. some models may require M-mode, and some models may support fully autonomous S-mode (the only M-mode function that exists is running on another core). e.g. Real-time.

Of course virtualization and real-time can be combined if the M-mode core can control interrupt routing tables on behalf of the running Supervisors. We could have multiple RTOS running with Supervisors that have pre-emptable User tasks and the virtual domains never need to enter M-mode, except perhaps for power on and power off. Maybe power management is in scope. One should probably chat to Linus about what he’d like to see... possibly not an in-kernel byte-code interpreter...


BTW Please do not swear on the list. Alex, Bruce, myself and the other posters have not written anything that warrants swearing at us. Many folk have been working away quietly in the open and the messages to the contrary are completely unfounded. Anyway this goes without saying. There is only one person swearing and shouting on this list.

Luke, you are incorrigible. Whether you are a bully or not is neither here nor there. Your behaviour on this mailing list is not acceptable. Try no shouting or swearing. Many have advised this before but there has been no change.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-10 19:41, Olof Johansson ??????:
> On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>> 
>> At Google and other places, we've been struggling now for years with
>> overly complex firmware that is implemented incorrectly, enabling
>> exploits and other bad things. The list of things vendors get wrong in
>> firmware, both enabling exploits and enabling others to enable
>> exploits, is long and it continues to this day. There is an
>> unbelievable amount of money out there all involving firmware
>> exploits, very little of it involving nice people.
>> 
>> I'm currently working on deleting all use of the x86 version of M
>> mode, i.e. SMM. There are many proposals out there for deleting SMM
>> from the architecture. I've also shown at a talk in 2017 how we could
>> redirect SMM interrupts back into the kernel. We're also removing all
>> use of callbacks into UEFI on x86. We're almost there.
>> 
>> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
>> proposals for M- mode code. PPP in firmware? Really? multiple serial
>> devices? really? We've been here before, in the 1970s, with something
>> called the BIOS. If you're not familiar with it, go take a look, or
>> you can take my word for it that these proposals implement that idea.
>> We spent over 20 years freeing ourselves from it on x86. Why go back
>> to a 50 year old model on a CPU designed to be in use for 50 years?
>> 
>> My early understanding of M mode was that it was an Alpha PALCode like
>> thing, enabling access to resources that were behind a privilege wall.
>> I did not like it that much, but I was OK: it was very limited in
>> function, and the kernel could replace it, or at least measure it. I
>> also accept that every cpu vendor uses m mode like things (e.g. ARM
>> TF) for reasonable purposes and also (let's be honest here)  for
>> dealing with chipset mistakes. But that does not mean you need to
>> recreate BIOS.
>> 
>> The SBI should be hard to add to, deliberately. It should be used only
>> when there are no possible alternatives. It needs to be open source
>> and held in common. It should be possible for a kernel to replace or
>> at least measure it. And, further, there needs to be some work done on
>> why you add to it, and why you don't, with bias against adding to it.
>> This proposal works against those ideals, as it explicitly enables
>> vendor-specific forks of the SBI. Sure, this can happen, but why make
>> it so easy?
> 
> There's a tension between letting people do the messy things that real
> hardware sometimes needs without polluting higher layers in the
> software stack, and letting them do too much of things that _should_
> be handled in the upper layers. I have yet to find a solution that
> doesn't need tweaking over time, the pendulum tends to swing back and
> forth into "too far" in both directions sometimes.
> 
> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
> 
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.
> 
> 

+1

>> p.s. For interleaving debug and console output firmware, use the
>> oldest trick in the book: ASCII is 7 bits. Since console out is 8
>> bits, reserve 128 values for console out, and 128 for debug stream,
>> and if the debug stream needs 8 bit for some words, you know what to
>> do. It's very easy and doesn't require that we add multiple UART
>> support to SBI.
> 
> Sure, it helps for 2 channels. And then beyond that you need a more
> complex protocol. Either way, it's not a problem we need to solve here
> and now.
> 

+1, most people will just use minicom/picocom to do their job, not 
implement
a protocol over serial for splitting main console from debug console.

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-10 19:41, Olof Johansson έγραψε:
> On Sat, Nov 10, 2018 at 8:46 AM ron minnich <rminnich@gmail.com> wrote:
>> 
>> At Google and other places, we've been struggling now for years with
>> overly complex firmware that is implemented incorrectly, enabling
>> exploits and other bad things. The list of things vendors get wrong in
>> firmware, both enabling exploits and enabling others to enable
>> exploits, is long and it continues to this day. There is an
>> unbelievable amount of money out there all involving firmware
>> exploits, very little of it involving nice people.
>> 
>> I'm currently working on deleting all use of the x86 version of M
>> mode, i.e. SMM. There are many proposals out there for deleting SMM
>> from the architecture. I've also shown at a talk in 2017 how we could
>> redirect SMM interrupts back into the kernel. We're also removing all
>> use of callbacks into UEFI on x86. We're almost there.
>> 
>> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
>> proposals for M- mode code. PPP in firmware? Really? multiple serial
>> devices? really? We've been here before, in the 1970s, with something
>> called the BIOS. If you're not familiar with it, go take a look, or
>> you can take my word for it that these proposals implement that idea.
>> We spent over 20 years freeing ourselves from it on x86. Why go back
>> to a 50 year old model on a CPU designed to be in use for 50 years?
>> 
>> My early understanding of M mode was that it was an Alpha PALCode like
>> thing, enabling access to resources that were behind a privilege wall.
>> I did not like it that much, but I was OK: it was very limited in
>> function, and the kernel could replace it, or at least measure it. I
>> also accept that every cpu vendor uses m mode like things (e.g. ARM
>> TF) for reasonable purposes and also (let's be honest here)  for
>> dealing with chipset mistakes. But that does not mean you need to
>> recreate BIOS.
>> 
>> The SBI should be hard to add to, deliberately. It should be used only
>> when there are no possible alternatives. It needs to be open source
>> and held in common. It should be possible for a kernel to replace or
>> at least measure it. And, further, there needs to be some work done on
>> why you add to it, and why you don't, with bias against adding to it.
>> This proposal works against those ideals, as it explicitly enables
>> vendor-specific forks of the SBI. Sure, this can happen, but why make
>> it so easy?
> 
> There's a tension between letting people do the messy things that real
> hardware sometimes needs without polluting higher layers in the
> software stack, and letting them do too much of things that _should_
> be handled in the upper layers. I have yet to find a solution that
> doesn't need tweaking over time, the pendulum tends to swing back and
> forth into "too far" in both directions sometimes.
> 
> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
> 
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.
> 
> 

+1

>> p.s. For interleaving debug and console output firmware, use the
>> oldest trick in the book: ASCII is 7 bits. Since console out is 8
>> bits, reserve 128 values for console out, and 128 for debug stream,
>> and if the debug stream needs 8 bit for some words, you know what to
>> do. It's very easy and doesn't require that we add multiple UART
>> support to SBI.
> 
> Sure, it helps for 2 channels. And then beyond that you need a more
> complex protocol. Either way, it's not a problem we need to solve here
> and now.
> 

+1, most people will just use minicom/picocom to do their job, not 
implement
a protocol over serial for splitting main console from debug console.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[ron minnich]

On Sat, Nov 10, 2018 at 9:42 AM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
>
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.


Totally agree. OK, so, at least we don't need the "index" in the SBI
call to pick a console, right?

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

On Sat, Nov 10, 2018 at 9:42 AM Olof Johansson <olof@lixom.net> wrote:

> The case of console is in this case pretty simple: It's intended for
> early boot for very simplistic environments (before the rest of the
> kernel is up, etc). Keeping the SBI console around beyond early boot,
> and somehow trying to optimize for it for those use cases is a
> misdirected effort; that's what native drivers are for.
>
> Having to do fine-grained arbitration of device ownership between
> firmware and kernel at runtime is usually error prone and awkward and
> best to avoid.


Totally agree. OK, so, at least we don't need the "index" in the SBI
call to pick a console, right?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Atish Patra]

On 11/10/18 8:46 AM, ron minnich wrote:
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
> 
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
> 
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
> 
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
> 
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. 

I completely agree with this. Once we finalize a decent SBI spec, any 
additional SBI call should be vetted through community and added only if 
**absolutely** necessary. I had echoed same thoughts for a request about 
adding SBI calls for perf & trigger modules in the mailing list.

It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?
> 

I think the larger picture might have lost somewhere because of the 
verbosity of the proposal. The idea of adding vendor extension support 
in SBI is to allow them provide a standard mechanism to facilitate this.
In absence of that, vendor might adopt different approaches to support 
their feature leading a lot of chaos. Vendors can not go and add 
anything in the Linux kernel(just a example, SBI is still OS agnostic) 
as well.

Example:
http://lists.infradead.org/pipermail/linux-riscv/2018-November/002086.html

I am not sure which part in the proposal led to the conclusion that 
adding vendor-specific forks will super easy. I am more than happy to 
correct it.

> see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.
> 

Thanks a lot for the review. I am going through the suggestions.


Regards,
Atish
> Also, I've had discussions with some security folks in our firmware
> community about the fact that the PMP can be used in a way that the
> kernel can not measure the SBI, since SBI might read-protect itself.
> This is a real step backwards, FYI. Not sure if it can be changed at
> this point.
> 
> ron
> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.
> On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
>>
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>>
>>> ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
>>>> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>>>> wrote:
>>>>
>>>>> ## Conclusion
>>>>> This proposal is far from perfect and absolutely any suggestion is
>>>>> welcome. Obviously, there are many other functionalities that can be
>>>>> added to this proposal. However, I just wanted to start with something
>>>>> that is an incremental change at best to kick off the discussion. The
>>>>> aim here is to initiate a discussion that can lead to a robust SBI
>>>>> specification.
>>>>
>>>>   very cool, atish.
>>>>
>>>>   i would very much like to see the optional addition of multiple
>>>> serial lines, by adding a getchar and putchar function that takes just
>>>> one extra argument: the serial line index.
>>>>
>>>>   there are a lot of different uses to which mult-serial lines may be
>>>> put:
>>>>
>>>>   * boot message separation from console login
>>>>   * boot management separation from other purposes (u-boot/coreboot)
>>>>   * virtual /dev/ttyS0-3
>>>>   * clean UPS reporting and management
>>>>   * remote virtual machine power management (power-on / off)
>>>>   * simple bog-standard multiple virtual login consoles
>>>>   * separation of debug messages (stdout/stderr) to ease debugging and
>>>> development
>>>>   * remote and virtual OpenOCD and kernel debugging without disrupting
>>>> the main serial console
>>>>   * PPP serial links.
>>>>
>>>> this latter is one that i am particularly interested in, as i would
>>>> like to be able to boot a full GNU/Linux OS on spike, given the lower
>>>> barrier to entry in making modifications and experimenting with spike
>>>> than it is with qemu.
>>>>
>>>>   if spike were able, through a multi-serial SBI interface, to have a
>>>> PPP serial line, it would be possible to run a root NFS (or other
>>>> network block device) without having to sacrifice console access.  it
>>>> would be possible to create an initramfs from a lower-capability
>>>> system like buildroot, containing PPP, enable it, and pivot-root out
>>>> to a full stock GNU/Linux OS such as debian or fedora.
>>>>
>>>>   so there are huge benefits, reducing the development barrier to entry
>>>> into RISC-V experimentation and debugging, and opening up a much wider
>>>> range of capabilities and possibilities for machine and virtual system
>>>> management.
>>>>
>>>> l.
>>>
>>>
>>> The current SBI says that console_getchar/console_putchar are for the
>>> debug
>>> console but on Linux we use them for the main console on earlyprintk.
>>
>>   ... yeah exactly.  and what if something goes wrong, you want to be
>> able to interact over openocd without interfering with that
>> earlyprintk, particularly during that critical first bringup phase of
>> real-world silicon?
>>
>>> I
>>> think it's misleading and we should at least have an argument to chose
>>> between the main console and an optional debug console, or rename
>>> them to debug_console_getchar/debug_console_putchar and
>>> main_console_getchar/
>>> main_console_putchar.
>>
>>   i initially thought of proposing that, however:
>>
>>   (1) the API already exists with "single console". it would therefore
>> be disruptive to change that
>>
>>   (2) if adding something called debug_console_{get/put}char, it might
>> as well take advantage of the opportunity to be extended and made
>> generic, and have the extra argument added
>>
>>> However I don't think that argument should be the serial line. Different
>>> vendors may use different serial lines for the main console / debug
>>> console,
>>> the caller doesn't know which serial line maps to which console, so the
>>> SBI
>>> should be more abstract and use something like a console id where e.g. 0
>>> is
>>> main console an 1 is debug.
>>
>>   yes, it should [have]: my feeling is, it's a little late in the game
>> given that it's almost certainly baked into pre-existing hardware, by
>> now, so the next best thing is a new function call.
>>
>> l.
>>
>> --
>> 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 at groups.riscv.org.
>> To post to this group, send email to sw-dev at 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/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.
> 

Re: [sw-dev] SBI extension proposal v2

[Atish Patra]

On 11/10/18 8:46 AM, ron minnich wrote:
> At Google and other places, we've been struggling now for years with
> overly complex firmware that is implemented incorrectly, enabling
> exploits and other bad things. The list of things vendors get wrong in
> firmware, both enabling exploits and enabling others to enable
> exploits, is long and it continues to this day. There is an
> unbelievable amount of money out there all involving firmware
> exploits, very little of it involving nice people.
> 
> I'm currently working on deleting all use of the x86 version of M
> mode, i.e. SMM. There are many proposals out there for deleting SMM
> from the architecture. I've also shown at a talk in 2017 how we could
> redirect SMM interrupts back into the kernel. We're also removing all
> use of callbacks into UEFI on x86. We're almost there.
> 
> Which is why I'm a bit unhappy to see this (to me) cancerous growth in
> proposals for M- mode code. PPP in firmware? Really? multiple serial
> devices? really? We've been here before, in the 1970s, with something
> called the BIOS. If you're not familiar with it, go take a look, or
> you can take my word for it that these proposals implement that idea.
> We spent over 20 years freeing ourselves from it on x86. Why go back
> to a 50 year old model on a CPU designed to be in use for 50 years?
> 
> My early understanding of M mode was that it was an Alpha PALCode like
> thing, enabling access to resources that were behind a privilege wall.
> I did not like it that much, but I was OK: it was very limited in
> function, and the kernel could replace it, or at least measure it. I
> also accept that every cpu vendor uses m mode like things (e.g. ARM
> TF) for reasonable purposes and also (let's be honest here)  for
> dealing with chipset mistakes. But that does not mean you need to
> recreate BIOS.
> 
> The SBI should be hard to add to, deliberately. It should be used only
> when there are no possible alternatives. It needs to be open source
> and held in common. 

I completely agree with this. Once we finalize a decent SBI spec, any 
additional SBI call should be vetted through community and added only if 
**absolutely** necessary. I had echoed same thoughts for a request about 
adding SBI calls for perf & trigger modules in the mailing list.

It should be possible for a kernel to replace or
> at least measure it. And, further, there needs to be some work done on
> why you add to it, and why you don't, with bias against adding to it.
> This proposal works against those ideals, as it explicitly enables
> vendor-specific forks of the SBI. Sure, this can happen, but why make
> it so easy?
> 

I think the larger picture might have lost somewhere because of the 
verbosity of the proposal. The idea of adding vendor extension support 
in SBI is to allow them provide a standard mechanism to facilitate this.
In absence of that, vendor might adopt different approaches to support 
their feature leading a lot of chaos. Vendors can not go and add 
anything in the Linux kernel(just a example, SBI is still OS agnostic) 
as well.

Example:
http://lists.infradead.org/pipermail/linux-riscv/2018-November/002086.html

I am not sure which part in the proposal led to the conclusion that 
adding vendor-specific forks will super easy. I am more than happy to 
correct it.

> see https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts.
> 

Thanks a lot for the review. I am going through the suggestions.


Regards,
Atish
> Also, I've had discussions with some security folks in our firmware
> community about the fact that the PMP can be used in a way that the
> kernel can not measure the SBI, since SBI might read-protect itself.
> This is a real step backwards, FYI. Not sure if it can be changed at
> this point.
> 
> ron
> p.s. For interleaving debug and console output firmware, use the
> oldest trick in the book: ASCII is 7 bits. Since console out is 8
> bits, reserve 128 values for console out, and 128 for debug stream,
> and if the debug stream needs 8 bit for some words, you know what to
> do. It's very easy and doesn't require that we add multiple UART
> support to SBI.
> On Sat, Nov 10, 2018 at 7:49 AM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
>>
>> ---
>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>
>> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote:
>>>
>>> Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
>>>> On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>>>> wrote:
>>>>
>>>>> ## Conclusion
>>>>> This proposal is far from perfect and absolutely any suggestion is
>>>>> welcome. Obviously, there are many other functionalities that can be
>>>>> added to this proposal. However, I just wanted to start with something
>>>>> that is an incremental change at best to kick off the discussion. The
>>>>> aim here is to initiate a discussion that can lead to a robust SBI
>>>>> specification.
>>>>
>>>>   very cool, atish.
>>>>
>>>>   i would very much like to see the optional addition of multiple
>>>> serial lines, by adding a getchar and putchar function that takes just
>>>> one extra argument: the serial line index.
>>>>
>>>>   there are a lot of different uses to which mult-serial lines may be
>>>> put:
>>>>
>>>>   * boot message separation from console login
>>>>   * boot management separation from other purposes (u-boot/coreboot)
>>>>   * virtual /dev/ttyS0-3
>>>>   * clean UPS reporting and management
>>>>   * remote virtual machine power management (power-on / off)
>>>>   * simple bog-standard multiple virtual login consoles
>>>>   * separation of debug messages (stdout/stderr) to ease debugging and
>>>> development
>>>>   * remote and virtual OpenOCD and kernel debugging without disrupting
>>>> the main serial console
>>>>   * PPP serial links.
>>>>
>>>> this latter is one that i am particularly interested in, as i would
>>>> like to be able to boot a full GNU/Linux OS on spike, given the lower
>>>> barrier to entry in making modifications and experimenting with spike
>>>> than it is with qemu.
>>>>
>>>>   if spike were able, through a multi-serial SBI interface, to have a
>>>> PPP serial line, it would be possible to run a root NFS (or other
>>>> network block device) without having to sacrifice console access.  it
>>>> would be possible to create an initramfs from a lower-capability
>>>> system like buildroot, containing PPP, enable it, and pivot-root out
>>>> to a full stock GNU/Linux OS such as debian or fedora.
>>>>
>>>>   so there are huge benefits, reducing the development barrier to entry
>>>> into RISC-V experimentation and debugging, and opening up a much wider
>>>> range of capabilities and possibilities for machine and virtual system
>>>> management.
>>>>
>>>> l.
>>>
>>>
>>> The current SBI says that console_getchar/console_putchar are for the
>>> debug
>>> console but on Linux we use them for the main console on earlyprintk.
>>
>>   ... yeah exactly.  and what if something goes wrong, you want to be
>> able to interact over openocd without interfering with that
>> earlyprintk, particularly during that critical first bringup phase of
>> real-world silicon?
>>
>>> I
>>> think it's misleading and we should at least have an argument to chose
>>> between the main console and an optional debug console, or rename
>>> them to debug_console_getchar/debug_console_putchar and
>>> main_console_getchar/
>>> main_console_putchar.
>>
>>   i initially thought of proposing that, however:
>>
>>   (1) the API already exists with "single console". it would therefore
>> be disruptive to change that
>>
>>   (2) if adding something called debug_console_{get/put}char, it might
>> as well take advantage of the opportunity to be extended and made
>> generic, and have the extra argument added
>>
>>> However I don't think that argument should be the serial line. Different
>>> vendors may use different serial lines for the main console / debug
>>> console,
>>> the caller doesn't know which serial line maps to which console, so the
>>> SBI
>>> should be more abstract and use something like a console id where e.g. 0
>>> is
>>> main console an 1 is debug.
>>
>>   yes, it should [have]: my feeling is, it's a little late in the game
>> given that it's almost certainly baked into pre-existing hardware, by
>> now, so the next best thing is a new function call.
>>
>> l.
>>
>> --
>> 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-dev@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/CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ%3D44A%40mail.gmail.com.
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Benjamin Herrenschmidt]

On Sat, 2018-11-10 at 19:58 -0800, Atish Patra wrote:
> 
> I think the larger picture might have lost somewhere because of the 
> verbosity of the proposal. The idea of adding vendor extension support 
> in SBI is to allow them provide a standard mechanism to facilitate this.
> In absence of that, vendor might adopt different approaches to support 
> their feature leading a lot of chaos. Vendors can not go and add 
> anything in the Linux kernel(just a example, SBI is still OS agnostic) 
> as well.

The concept of vendor extensions to a userspace ISA is so fundamentally
broken to begin with, this FW proposal verges on utter insanity to be
honest.

Calling FW for things so deeply ingrained in the kernel such as context
swithes, isn't going to fly. The performance will be ridiculously bad,
among other things.

If Risc-V wants to avoid fragmentation, it should simply keep a firmer
reign in what is allowed in an implementation and keep a lid on such
horrid ideas as vendor specific userspace ISA extensions.

Cheers,
Ben.



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

On 02.12.18 07:18, Benjamin Herrenschmidt wrote:
> On Sat, 2018-11-10 at 19:58 -0800, Atish Patra wrote:
>>
>> I think the larger picture might have lost somewhere because of the 
>> verbosity of the proposal. The idea of adding vendor extension support 
>> in SBI is to allow them provide a standard mechanism to facilitate this.
>> In absence of that, vendor might adopt different approaches to support 
>> their feature leading a lot of chaos. Vendors can not go and add 
>> anything in the Linux kernel(just a example, SBI is still OS agnostic) 
>> as well.
> 
> The concept of vendor extensions to a userspace ISA is so fundamentally
> broken to begin with, this FW proposal verges on utter insanity to be
> honest.

Where exactly do you see mentioned that this would be for user space?

> Calling FW for things so deeply ingrained in the kernel such as context
> swithes, isn't going to fly. The performance will be ridiculously bad,
> among other things.

Yes, but I haven't seen anyone propose SBI calls in fast paths?

What I would like to see SBI is used for is:

  * clocks
  * regulators
  * [debug interface (like your debug serial), has the after taste of
BIOS though]
  * power control
  * TEE switch-over

Basically, everything that PSCI and SCMI do on ARM.

Beyond that, there should be very little need for anything in SBI from
what I can tell? Even the IPI mechanism seems ... eh ... odd to me.

Atish, can you please elaborate what exactly you were thinking of as
vendor extensions?

> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
> reign in what is allowed in an implementation and keep a lid on such
> horrid ideas as vendor specific userspace ISA extensions.

I tend to agree here. I think a global identification scheme is
reasonable. But can't we just live with a single global spec that people
contribute to?

That way, people can educate each other on "bad ideas" as well as maybe
see potential for overlapping functionality that multiple vendors may have.


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:

> > If Risc-V wants to avoid fragmentation, it should simply keep a firmer
> > reign in what is allowed in an implementation and keep a lid on such
> > horrid ideas as vendor specific userspace ISA extensions.
>
> I tend to agree here. I think a global identification scheme is
> reasonable. But can't we just live with a single global spec that people
> contribute to?

 unfortunately, alexander, the RISC-V Foundation has chosen to exclude
people from the discussion, by choosing an ITU-style ("Cartelled")
secretive standards development process.

 so as an "outsider" who for whatever reason cannot join that closed,
secretive process (for example a strategically-critical u-boot or
linux kernel developer with decades of relevant experience but who is
under contract) even if you wanted to contribute to a single global
spec, you can't.

 the reasons why the ITU-style Cartel was set up have been discussed
and made clear (patents); the justifications were knocked down; there
was no response.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

On 28.01.19 17:33, Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:
> 
>>> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
>>> reign in what is allowed in an implementation and keep a lid on such
>>> horrid ideas as vendor specific userspace ISA extensions.
>>
>> I tend to agree here. I think a global identification scheme is
>> reasonable. But can't we just live with a single global spec that people
>> contribute to?
> 
>  unfortunately, alexander, the RISC-V Foundation has chosen to exclude
> people from the discussion, by choosing an ITU-style ("Cartelled")
> secretive standards development process.
> 
>  so as an "outsider" who for whatever reason cannot join that closed,
> secretive process (for example a strategically-critical u-boot or
> linux kernel developer with decades of relevant experience but who is
> under contract) even if you wanted to contribute to a single global
> spec, you can't.
> 
>  the reasons why the ITU-style Cartel was set up have been discussed
> and made clear (patents); the justifications were knocked down; there
> was no response.

I can see why you want to have a process like that in place for the ISA
itself, but the SBI spec really should not have anything "innovative" or
patentable. At the end of the day, it's a communication mechanism.


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2019-01-28 18:38, Alexander Graf έγραψε:
> On 28.01.19 17:33, Luke Kenneth Casson Leighton wrote:
>> ---
>> crowd-funded eco-conscious hardware: 
>> https://www.crowdsupply.com/eoma68
>> 
>> On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:
>> 
>>>> If Risc-V wants to avoid fragmentation, it should simply keep a 
>>>> firmer
>>>> reign in what is allowed in an implementation and keep a lid on such
>>>> horrid ideas as vendor specific userspace ISA extensions.
>>> 
>>> I tend to agree here. I think a global identification scheme is
>>> reasonable. But can't we just live with a single global spec that 
>>> people
>>> contribute to?
>> 
>>  unfortunately, alexander, the RISC-V Foundation has chosen to exclude
>> people from the discussion, by choosing an ITU-style ("Cartelled")
>> secretive standards development process.
>> 
>>  so as an "outsider" who for whatever reason cannot join that closed,
>> secretive process (for example a strategically-critical u-boot or
>> linux kernel developer with decades of relevant experience but who is
>> under contract) even if you wanted to contribute to a single global
>> spec, you can't.
>> 
>>  the reasons why the ITU-style Cartel was set up have been discussed
>> and made clear (patents); the justifications were knocked down; there
>> was no response.
> 
> I can see why you want to have a process like that in place for the ISA
> itself, but the SBI spec really should not have anything "innovative" 
> or
> patentable. At the end of the day, it's a communication mechanism.
> 
> 
> Alex

FYI
https://fosdem.org/2019/schedule/event/riscvsbi/

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

On 28.01.19 17:47, Nick Kossifidis wrote:
> Στις 2019-01-28 18:38, Alexander Graf έγραψε:
>> On 28.01.19 17:33, Luke Kenneth Casson Leighton wrote:
>>> ---
>>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>>
>>> On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:
>>>
>>>>> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
>>>>> reign in what is allowed in an implementation and keep a lid on such
>>>>> horrid ideas as vendor specific userspace ISA extensions.
>>>>
>>>> I tend to agree here. I think a global identification scheme is
>>>> reasonable. But can't we just live with a single global spec that
>>>> people
>>>> contribute to?
>>>
>>>  unfortunately, alexander, the RISC-V Foundation has chosen to exclude
>>> people from the discussion, by choosing an ITU-style ("Cartelled")
>>> secretive standards development process.
>>>
>>>  so as an "outsider" who for whatever reason cannot join that closed,
>>> secretive process (for example a strategically-critical u-boot or
>>> linux kernel developer with decades of relevant experience but who is
>>> under contract) even if you wanted to contribute to a single global
>>> spec, you can't.
>>>
>>>  the reasons why the ITU-style Cartel was set up have been discussed
>>> and made clear (patents); the justifications were knocked down; there
>>> was no response.
>>
>> I can see why you want to have a process like that in place for the ISA
>> itself, but the SBI spec really should not have anything "innovative" or
>> patentable. At the end of the day, it's a communication mechanism.
>>
>>
>> Alex
> 
> FYI
> https://fosdem.org/2019/schedule/event/riscvsbi/

That one is overlapping with on I will be co-presenting on:

  https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/

But I'm sure we can discuss things regardless one way or another :).


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Atish Patra]

On 1/28/19 11:43 AM, Alexander Graf wrote:
> 
> 
> On 28.01.19 17:47, Nick Kossifidis wrote:
>> Στις 2019-01-28 18:38, Alexander Graf έγραψε:
>>> On 28.01.19 17:33, Luke Kenneth Casson Leighton wrote:
>>>> ---
>>>> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>>>>
>>>> On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>>> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
>>>>>> reign in what is allowed in an implementation and keep a lid on such
>>>>>> horrid ideas as vendor specific userspace ISA extensions.
>>>>>
>>>>> I tend to agree here. I think a global identification scheme is
>>>>> reasonable. But can't we just live with a single global spec that
>>>>> people
>>>>> contribute to?
>>>>
>>>>   unfortunately, alexander, the RISC-V Foundation has chosen to exclude
>>>> people from the discussion, by choosing an ITU-style ("Cartelled")
>>>> secretive standards development process.
>>>>
>>>>   so as an "outsider" who for whatever reason cannot join that closed,
>>>> secretive process (for example a strategically-critical u-boot or
>>>> linux kernel developer with decades of relevant experience but who is
>>>> under contract) even if you wanted to contribute to a single global
>>>> spec, you can't.
>>>>
>>>>   the reasons why the ITU-style Cartel was set up have been discussed
>>>> and made clear (patents); the justifications were knocked down; there
>>>> was no response.
>>>
>>> I can see why you want to have a process like that in place for the ISA
>>> itself, but the SBI spec really should not have anything "innovative" or
>>> patentable. At the end of the day, it's a communication mechanism.
>>>
>>>
>>> Alex
>>
>> FYI
>> https://fosdem.org/2019/schedule/event/riscvsbi/
> 
> That one is overlapping with on I will be co-presenting on:
> 
>    https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/
> 
Great. Your talk is on Sunday. SBI talk is on Saturday.

Looking forward to attend this one as well.

> But I'm sure we can discuss things regardless one way or another :).
> 

Definitely.

Regards,
Atish
> 
> Alex
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

On 28.01.19 20:47, Atish Patra wrote:
> On 1/28/19 11:43 AM, Alexander Graf wrote:
>>
>>
>> On 28.01.19 17:47, Nick Kossifidis wrote:
>>> FYI
>>> https://fosdem.org/2019/schedule/event/riscvsbi/
>>
>> That one is overlapping with on I will be co-presenting on:
>>
>>    https://fosdem.org/2019/schedule/event/uefi_boot_for_mere_mortals/
>>
> Great. Your talk is on Sunday. SBI talk is on Saturday.

Minor details :). Thanks for catching the difference in days, I'll be
there then!


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

Those of us working on the linuxboot and heads projects for the last
few years have reached a few conclusions in this area. The big one --
vendors can not get firmware right, period. The set of bugs we've hit
in the x86 world alone in the last two years is just amazing, given
that the UEFI community has had 20 years to get this stuff right and
still don't seem to be able to do it. What's more amazing is how
trivial they are. Do you want to disable UEFI mechanisms for detecting
ROM image corruption? It's easy on many systems. Corrupt the ROM
image. Achievement. as well as the ROM, unlocked. I'm not making this
up; it's several CVEs at this point.

We've learned that blindly  trusting firmware is always a bad idea.
Assuming that it should have higher privilege, and trust, than the
kernel is, similarly, a bad idea. In general, kernel code is far
superior in quality to firmware, and is certainly better tested. Why
is firmware higher privilege, when it's not as well written or
trustworthy? That makes no sense. It's the assumption RISCV is making.

Maybe the most important thing we now believe is that firmware should
be measurable by the owner, i.e that an end user or system needs to be
able to see what's there. Following on that, it's most desirable if
firmware functions can be disabled and in some cases the firmware can
be completely replaced, post boot, by the kernel, with something it
can trust. The M mode, conceptually, is just a different type of trap
handler. This is a lot like the work I did a few years back to vector
SMM traps to the kernel, not buggy vendor SMM code.

From that perspective, the "M mode bug" was never a bug -- I never
agreed with Don on this one -- because it guaranteed a kernel could
measure, disable, and replace firmware. And that's important, because
firmware that is more powerful than the kernel should be easier to
change out than the kernel. And that's another thing vendors keep
screwing up. There is a recent proof of concept that installs UEFI on
vulnerable x86 systems and then sets the one time fuses in such a way
that the firmware can not be replaced unless the CPU is too. I'm not
making this up either, and it's due to a screwup in the manufacturing
flow of some ODMs, who left those fuses open. There are exploits in
the wild that are only resolved with a chipper.

Short form: if the PMP makes it impossible to measure, disable and
replace firmware from the kernel, then PMP is a bug, not a feature.

I just now had a conversation with a friend from chromeos firmware
team and he is similarly dismayed with the directions riscv is taking,
especially as regards runtime firmware. When I mentioned PSCI he
looked sad.

I understand the motivation to fit a new architecture into old
firmware clothes. It's just that the clothes are motheaten and out of
style and never looked good when new. We're going to need to have an
escape hatch for organizations looking for newer, better ways of doing
things.

One possible way out at some point might be to define an SBI interface
and operating mode that is responsive to concerns about firmware
security, and avoiding the mistakes of the past. This does mean that
there will not be "one SBI", which in turn means different kernel
configurations, but I don't see much option. The concept of a "single
SBI" was always going to be hard, and I expect at this point it will
never happen.

ron



On Mon, Jan 28, 2019 at 8:38 AM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 28.01.19 17:33, Luke Kenneth Casson Leighton wrote:
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Mon, Jan 28, 2019 at 12:44 PM Alexander Graf <agraf@suse.de> wrote:
> >
> >>> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
> >>> reign in what is allowed in an implementation and keep a lid on such
> >>> horrid ideas as vendor specific userspace ISA extensions.
> >>
> >> I tend to agree here. I think a global identification scheme is
> >> reasonable. But can't we just live with a single global spec that people
> >> contribute to?
> >
> >  unfortunately, alexander, the RISC-V Foundation has chosen to exclude
> > people from the discussion, by choosing an ITU-style ("Cartelled")
> > secretive standards development process.
> >
> >  so as an "outsider" who for whatever reason cannot join that closed,
> > secretive process (for example a strategically-critical u-boot or
> > linux kernel developer with decades of relevant experience but who is
> > under contract) even if you wanted to contribute to a single global
> > spec, you can't.
> >
> >  the reasons why the ITU-style Cartel was set up have been discussed
> > and made clear (patents); the justifications were knocked down; there
> > was no response.
>
> I can see why you want to have a process like that in place for the ISA
> itself, but the SBI spec really should not have anything "innovative" or
> patentable. At the end of the day, it's a communication mechanism.
>
>
> Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

Hi Ron,

On 28.01.19 20:40, ron minnich wrote:
> Those of us working on the linuxboot and heads projects for the last
> few years have reached a few conclusions in this area. The big one --
> vendors can not get firmware right, period. The set of bugs we've hit

Agreed.

> in the x86 world alone in the last two years is just amazing, given
> that the UEFI community has had 20 years to get this stuff right and
> still don't seem to be able to do it. What's more amazing is how
> trivial they are. Do you want to disable UEFI mechanisms for detecting
> ROM image corruption? It's easy on many systems. Corrupt the ROM
> image. Achievement. as well as the ROM, unlocked. I'm not making this
> up; it's several CVEs at this point.
> 
> We've learned that blindly  trusting firmware is always a bad idea.

Agreed.

> Assuming that it should have higher privilege, and trust, than the
> kernel is, similarly, a bad idea. In general, kernel code is far
> superior in quality to firmware, and is certainly better tested. Why
> is firmware higher privilege, when it's not as well written or
> trustworthy? That makes no sense. It's the assumption RISCV is making.

I agree to the first part, not the second.

You're mixing up 2 things (which is a pretty common fallacy I've come
across people who worked too much with x86 firmware): Design and
implementation.

I agree that we should hold firmware to the same standards as the OS. I
agree that I would not consider something more trustworthy that is
developed behind closed doors at a random vendor's site and every bug
fix costs a few $1000.

The conclusion that runtime firmware is a bad idea IMHO is wrong though.
By separating an OS from extremely hardware dependent details, you allow
for abstraction. You allow an OS to run on newer hardware for example.
It's a bit like how an OS can magically make NV-DIMMs available to user
space from 20 years ago. Firmware with runtime code can potentially make
today's OSs run on hardware from next year.

Now, if the firmware development model is so broken but at the same time
such firmware gives us the ability to abstract interfaces better, what
is the solution?

You obviously need to apply the same standards as you do for the OS to
firmware. It's why open firmware is so important. If you can't fix
issues yourself (or better yet, have a community around it), chances are
good that it will be broken.

But putting everything into Linux instead really is not the answer. The
only thing it does is break forward compatibility and bloat code size.


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

On Mon, Jan 28, 2019 at 11:55 AM Alexander Graf <agraf@suse.de> wrote:

> You're mixing up 2 things (which is a pretty common fallacy I've come
> across people who worked too much with x86 firmware): Design and
> implementation.

uhm, alex, I worked on or started the coreboot ports to
arm
arm64
ppc
riscv
alpha

I've been working on various non-x86 firmware for over 40 years,
starting in 8 bit days.

You should probably not assume too much about people.

> The conclusion that runtime firmware is a bad idea IMHO is wrong though.

We can agree to disagree. But please don't start by stating things
about my background; you don't know me and you're wrong.

Runtime firmware is acceptable *if and only if* the kernel can measure
it, disable it all or in part, or replace it.
That's a different statement than what you just said. I don't like
runtime firmware, but of course on RISCV there are few options
for some registers. But it is a very rare runtime firmware that is
implemented correctly or even well.

There is one company that is so concerned about M mode they are
implementing a RISCV CPU without it.

> Now, if the firmware development model is so broken but at the same time
> such firmware gives us the ability to abstract interfaces better, what
> is the solution?

you give me the information I need to write a driver. Done. That's
known to work. And for linuxboot systems, that's the only way it
works.That way, we have one driver to deal with, not two. Server
systems that work this way are being deployed today.

> You obviously need to apply the same standards as you do for the OS to
> firmware. It's why open firmware is so important.

Sure. It'd be nice if that worked, but it's essential to ensure it's
the only thing that works. It's important not to enable architecture
features that can be used to make open source firmware
difficult or impossible. PMP is one such feature, since it allows
firmware to lock down regions of memory and make them inaccessible to
the kernel.

In general, however, vendor firmware is extremely poorly written, and
I don't expect that to change.

> But putting everything into Linux instead really is not the answer. The
> only thing it does is break forward compatibility and bloat code size.

I am, today, fitting a linux kernel and full Go userland into about 3M
in SPI. For reference, this is smaller than the audio codec firmware
on some chipsets.

I don't agree with your claim.

That said, RISCV will have the SBI, and there is no getting around it
for certain purposes, but there's no reason to encourage growth.

ron

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

On 28.01.19 21:18, ron minnich wrote:
> On Mon, Jan 28, 2019 at 11:55 AM Alexander Graf <agraf@suse.de> wrote:
> 
>> You're mixing up 2 things (which is a pretty common fallacy I've come
>> across people who worked too much with x86 firmware): Design and
>> implementation.
> 
> uhm, alex, I worked on or started the coreboot ports to
> arm
> arm64
> ppc
> riscv
> alpha
> 
> I've been working on various non-x86 firmware for over 40 years,
> starting in 8 bit days.

I know.

> You should probably not assume too much about people.
> 
>> The conclusion that runtime firmware is a bad idea IMHO is wrong though.
> 
> We can agree to disagree. But please don't start by stating things
> about my background; you don't know me and you're wrong.

I'm fairly sure you know me about as well as I do know you ;).

> Runtime firmware is acceptable *if and only if* the kernel can measure
> it, disable it all or in part, or replace it.
> That's a different statement than what you just said. I don't like

Hm. Ok, it depends on your deployment model of course. I tend to agree
that runtime firmware should be an OS triggered interface. If the OS
doesn't ask it to do something, it shouldn't.

The big problem is when only firmware has the rights to do something and
you need to trust it. That brings us back to this discussion.

So yes, you can "disable" it, but not replace it. So you may lose
functionality if you choose not to call firmware.

The ususal answer I would have to that is to empower system owners to
build their own firmware (which allows them to replace bits), but I can
see how that doesn't always work for every case. I don't have a good
answer yet, but I'm sure there will be discussions at FOSDEM about it.

> runtime firmware, but of course on RISCV there are few options
> for some registers. But it is a very rare runtime firmware that is
> implemented correctly or even well.
> 
> There is one company that is so concerned about M mode they are
> implementing a RISCV CPU without it.
> 
>> Now, if the firmware development model is so broken but at the same time
>> such firmware gives us the ability to abstract interfaces better, what
>> is the solution?
> 
> you give me the information I need to write a driver. Done. That's
> known to work. And for linuxboot systems, that's the only way it
> works.That way, we have one driver to deal with, not two. Server
> systems that work this way are being deployed today.

Sweet. What if you want to support 10000 different types of servers? You
write one (or many) driver(s) each?

>> You obviously need to apply the same standards as you do for the OS to
>> firmware. It's why open firmware is so important.
> 
> Sure. It'd be nice if that worked, but it's essential to ensure it's
> the only thing that works. It's important not to enable architecture
> features that can be used to make open source firmware
> difficult or impossible. PMP is one such feature, since it allows
> firmware to lock down regions of memory and make them inaccessible to
> the kernel.
> 
> In general, however, vendor firmware is extremely poorly written, and
> I don't expect that to change.
> 
>> But putting everything into Linux instead really is not the answer. The
>> only thing it does is break forward compatibility and bloat code size.
> 
> I am, today, fitting a linux kernel and full Go userland into about 3M
> in SPI. For reference, this is smaller than the audio codec firmware
> on some chipsets.

Does that same kernel run on all the 10000 different types of servers I
mentioned above?

The problem is not to build something for *one* configuration, it's how
we can abstract pieces well enough so that we can have a single system
image that runs on any system you throw it at.

> I don't agree with your claim.
> 
> That said, RISCV will have the SBI, and there is no getting around it
> for certain purposes, but there's no reason to encourage growth.

At least here we do agree (mostly) :).


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

On Mon, Jan 28, 2019 at 12:37 PM Alexander Graf <agraf@suse.de> wrote:

> I'm fairly sure you know me about as well as I do know you ;).

Apologies Alexandar, you're right. You're one of the good guys in this game.

> The ususal answer I would have to that is to empower system owners to
> build their own firmware (which allows them to replace bits), but I can
> see how that doesn't always work for every case. I don't have a good
> answer yet, but I'm sure there will be discussions at FOSDEM about it.

I wish that model worked. I've worked so hard to make it so for 20
years. But I know from long sad experience it does not.

I wish vendors would not keep installing exploits in the firmware. But
I know from long
sad experience they will keep doing that.

I wish it were as easy to install firmware as it is to install a
kernel. That's not
ever going to happen.

The one thing I know is that it is pretty easy to load a kernel of
choice, and for that
reason I want to allow the kernel to load the desired runtime firmware.
I don't like hardware that does not allow that.

IOW, the barrier to entry for firmware, we've found, is very high for
most people. The barrier
to kernel is far lower. Ergo, I'd like to have it at least *be
possible* for a kernel to measure, disable, or replace
the runtime firmware it will use. Measurement is a minimum and
non-negotiable requirement. If a RISCV system
ever sets up a PMP such that firmware can not be measured, that system
should be assumed to be untrustable.

This was easy before PMP. I am worried that it becomes impossible after it.

> Sweet. What if you want to support 10000 different types of servers? You
> write one (or many) driver(s) each?

that code is going to be written in any case. Do we write for UEFI
(painful!) or Linux (painful--)?

> Does that same kernel run on all the 10000 different types of servers I
> mentioned above?

It runs on a huge range of servers, at this point every OCP server
we've tested, several proprietary servers from an unnamed company, the
Intel NUC, and chromebooks I've tried, as well as PC Engines boards.
But, that said, the system needs to run part of coreboot or the
SEC/PEI part of UEFI; in the SEC/PEI case, that's a blob we will never
be allowed to replace, so it has to be assumed anyway :-(
And it relies on the early NON-runtime startup that the rom-based
firmware does. But our goal is to completely disable all UEFI runtime
services and SMM. runtime firmware services have proven to be too
large
a security problem to be allowed on x86.

> At least here we do agree (mostly) :).

Well, TBH, I think your vision will probably be the one that will be
used, whether I like it or not :-)
Looking forward to seeing you at FOSDEM!

ron

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Alexander Graf]

On 28.01.19 23:23, ron minnich wrote:
> On Mon, Jan 28, 2019 at 12:37 PM Alexander Graf <agraf@suse.de> wrote:
> 
>> I'm fairly sure you know me about as well as I do know you ;).
> 
> Apologies Alexandar, you're right. You're one of the good guys in this game.
> 
>> The ususal answer I would have to that is to empower system owners to
>> build their own firmware (which allows them to replace bits), but I can
>> see how that doesn't always work for every case. I don't have a good
>> answer yet, but I'm sure there will be discussions at FOSDEM about it.
> 
> I wish that model worked. I've worked so hard to make it so for 20
> years. But I know from long sad experience it does not.
> 
> I wish vendors would not keep installing exploits in the firmware. But
> I know from long
> sad experience they will keep doing that.

Well, any software has bugs. In a lot of cases the problems in firmware
are not deliberate - they just happen because everyone does mistakes.

That's why updatability *on every layer* is so important.

> I wish it were as easy to install firmware as it is to install a
> kernel. That's not
> ever going to happen.

In my book, with fwupd we're getting quite close. You can just deliver
firmware updates via normal Linux distro update mechanisms. So if you
want to maintain your own fork of firmware with your own keys etc, you can.

> The one thing I know is that it is pretty easy to load a kernel of
> choice, and for that
> reason I want to allow the kernel to load the desired runtime firmware.
> I don't like hardware that does not allow that.

I think there are 2 messages here that I agree with:

  1) Runtime firmware should never be interrupt driven

That way we ensure that the OS is the caller - always. If runtime
firmware needs an event mechanism, it should register it through the OS.

I really like that requirement. It is critical for any real time system
anyway. And at the same time ensures that you don't have random code
doing things behind your back.

  2) There must be a plan B when FW runtime is wrong

So if I read things in your email correctly, you're basically advocating
a typical ACPI model, where the kernel receives bytecode it executes
itself and thus can measure and replace it.

There are multiple problems with that:

  a) You are running at a different privilege level, so you may not have
access to the registers

  b) ACPI interpreters are *huge*. One big complaint I've seen in the
ARM world is when you get down to bare metal / partitioning hypervisors.
You will suddenly need a giant ACPI interpreter in your safety critical
domain, just to toggle clocks. And then another full framework for your
guest interface.

I think we're early enough in RISC-V to be able to mandate a few FW
constraints though. In my book, all that needs is that a FW supplier
needs to provide one out of 3 mechanisms:

  a) (runtime) open source, user replaceable FW and/or
  b) direct exposure to functionality done via runtime services using
alternate methods (trivial SBI functions for direct register access for
example) plus documentation and/or
  c) runtime code is directly interpreted by OS



If someone writes up a spec similar to SBBR that just mandates one out
of those 3 mechanisms and mandates that M mode may not receive
interrupts, I guess you would always get a system that you can unbrick /
eventually trust.

Now the really interesting question is what TEE looks like in such an
environment. How would a TEE application interact with hardware when it
can not get interrupts?

Oh well, lots of food for thought for discussions at FOSDEM.

> IOW, the barrier to entry for firmware, we've found, is very high for
> most people. The barrier
> to kernel is far lower. Ergo, I'd like to have it at least *be
> possible* for a kernel to measure, disable, or replace
> the runtime firmware it will use. Measurement is a minimum and
> non-negotiable requirement. If a RISCV system
> ever sets up a PMP such that firmware can not be measured, that system
> should be assumed to be untrustable.
> 
> This was easy before PMP. I am worried that it becomes impossible after it.

It depends. If you build and sign FW yourself, I see little reason not
to have lock-down mechanisms. At that point, you're trusting your own
code after all and you have your own update mechanism in place too.

>> Sweet. What if you want to support 10000 different types of servers? You
>> write one (or many) driver(s) each?
> 
> that code is going to be written in any case. Do we write for UEFI
> (painful!) or Linux (painful--)?

That's not really the question. It's the code vs binary model.

Look back at the old ARM days in Linux where every *board* had its own
.c file and there were a lot of hard coded #ifdefs scattered throughout
the code base because people knew that the OS would only ever get built
for one particular target.

Well, fortunately that has changed. People are now building a single
Linux binary for 10000 different targets. It was quite a lot of effort
to get to that point, but it allows for much better scaling of manpower.

I see a similar trend happening in firmware land. Take a look at André
Przywara's presentation at FOSDEM. For usability reasons there is a
certain desire to cover more than just a single target platform with a
single binary.

So while I agree that writing edk2 code is painful and writing Linux
code is much less so, that's not the question.

(Also, please don't call edk2 UEFI. There is so much in the UEFI spec
and most people really don't care about most of the driver bits. You can
use U-Boot just fine as UEFI provider and in fact you could even use
Linux as UEFI provider with an appropriate user space that implements
the services)

>> Does that same kernel run on all the 10000 different types of servers I
>> mentioned above?
> 
> It runs on a huge range of servers, at this point every OCP server
> we've tested, several proprietary servers from an unnamed company, the
> Intel NUC, and chromebooks I've tried, as well as PC Engines boards.

Is that the same source base or the exact same target binary? If it's
the same target binary, the only way I can see this work is if you have
runtime services in the form of a DSDT.

> But, that said, the system needs to run part of coreboot or the
> SEC/PEI part of UEFI; in the SEC/PEI case, that's a blob we will never
> be allowed to replace, so it has to be assumed anyway :-(

To be completely frank here, I don't see why someone as big as your
employer can't replace whatever they like. Others seem to be able to?

> And it relies on the early NON-runtime startup that the rom-based
> firmware does. But our goal is to completely disable all UEFI runtime
> services and SMM. runtime firmware services have proven to be too
> large
> a security problem to be allowed on x86.

I think you'll be happy to hear that as part of the EBBR discussions we
ended up with a UEFI ECR that will make it perfectly legal not to UEFI
have runtime services:

  https://pjones.fedorapeople.org/rt-unsupported-ecr-0.txt

Though I perfectly consider UEFI RTS not the worst part of this puzzle,
since they run in the same privilege level and they are only ever called
by the OS.

>> At least here we do agree (mostly) :).
> 
> Well, TBH, I think your vision will probably be the one that will be
> used, whether I like it or not :-)

I'm not sure I have a conclusive vision yet :).

> Looking forward to seeing you at FOSDEM!

Same here!


Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

This conversation is in danger of devolving into a lot of firmware
inside stories, so I'll keep it short, because I doubt most people
even care, and I don't want to bore anybody :-)

Any of uefi/edk2/whatever is so full of defects that, at least in my
world, we would not take the road through edkii unless we had no other
choice.

But, given that people want things like uefi/edk2/abc for their own
needs, again, I suspect the "SBI standard" is not going to be one
implementation and it may not be a standard. The opportunity to make
that happen passed 4 years ago.

thanks

ron

On Tue, Jan 29, 2019 at 12:53 AM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 28.01.19 23:23, ron minnich wrote:
> > On Mon, Jan 28, 2019 at 12:37 PM Alexander Graf <agraf@suse.de> wrote:
> >
> >> I'm fairly sure you know me about as well as I do know you ;).
> >
> > Apologies Alexandar, you're right. You're one of the good guys in this game.
> >
> >> The ususal answer I would have to that is to empower system owners to
> >> build their own firmware (which allows them to replace bits), but I can
> >> see how that doesn't always work for every case. I don't have a good
> >> answer yet, but I'm sure there will be discussions at FOSDEM about it.
> >
> > I wish that model worked. I've worked so hard to make it so for 20
> > years. But I know from long sad experience it does not.
> >
> > I wish vendors would not keep installing exploits in the firmware. But
> > I know from long
> > sad experience they will keep doing that.
>
> Well, any software has bugs. In a lot of cases the problems in firmware
> are not deliberate - they just happen because everyone does mistakes.
>
> That's why updatability *on every layer* is so important.
>
> > I wish it were as easy to install firmware as it is to install a
> > kernel. That's not
> > ever going to happen.
>
> In my book, with fwupd we're getting quite close. You can just deliver
> firmware updates via normal Linux distro update mechanisms. So if you
> want to maintain your own fork of firmware with your own keys etc, you can.
>
> > The one thing I know is that it is pretty easy to load a kernel of
> > choice, and for that
> > reason I want to allow the kernel to load the desired runtime firmware.
> > I don't like hardware that does not allow that.
>
> I think there are 2 messages here that I agree with:
>
>   1) Runtime firmware should never be interrupt driven
>
> That way we ensure that the OS is the caller - always. If runtime
> firmware needs an event mechanism, it should register it through the OS.
>
> I really like that requirement. It is critical for any real time system
> anyway. And at the same time ensures that you don't have random code
> doing things behind your back.
>
>   2) There must be a plan B when FW runtime is wrong
>
> So if I read things in your email correctly, you're basically advocating
> a typical ACPI model, where the kernel receives bytecode it executes
> itself and thus can measure and replace it.
>
> There are multiple problems with that:
>
>   a) You are running at a different privilege level, so you may not have
> access to the registers
>
>   b) ACPI interpreters are *huge*. One big complaint I've seen in the
> ARM world is when you get down to bare metal / partitioning hypervisors.
> You will suddenly need a giant ACPI interpreter in your safety critical
> domain, just to toggle clocks. And then another full framework for your
> guest interface.
>
> I think we're early enough in RISC-V to be able to mandate a few FW
> constraints though. In my book, all that needs is that a FW supplier
> needs to provide one out of 3 mechanisms:
>
>   a) (runtime) open source, user replaceable FW and/or
>   b) direct exposure to functionality done via runtime services using
> alternate methods (trivial SBI functions for direct register access for
> example) plus documentation and/or
>   c) runtime code is directly interpreted by OS
>
>
>
> If someone writes up a spec similar to SBBR that just mandates one out
> of those 3 mechanisms and mandates that M mode may not receive
> interrupts, I guess you would always get a system that you can unbrick /
> eventually trust.
>
> Now the really interesting question is what TEE looks like in such an
> environment. How would a TEE application interact with hardware when it
> can not get interrupts?
>
> Oh well, lots of food for thought for discussions at FOSDEM.
>
> > IOW, the barrier to entry for firmware, we've found, is very high for
> > most people. The barrier
> > to kernel is far lower. Ergo, I'd like to have it at least *be
> > possible* for a kernel to measure, disable, or replace
> > the runtime firmware it will use. Measurement is a minimum and
> > non-negotiable requirement. If a RISCV system
> > ever sets up a PMP such that firmware can not be measured, that system
> > should be assumed to be untrustable.
> >
> > This was easy before PMP. I am worried that it becomes impossible after it.
>
> It depends. If you build and sign FW yourself, I see little reason not
> to have lock-down mechanisms. At that point, you're trusting your own
> code after all and you have your own update mechanism in place too.
>
> >> Sweet. What if you want to support 10000 different types of servers? You
> >> write one (or many) driver(s) each?
> >
> > that code is going to be written in any case. Do we write for UEFI
> > (painful!) or Linux (painful--)?
>
> That's not really the question. It's the code vs binary model.
>
> Look back at the old ARM days in Linux where every *board* had its own
> .c file and there were a lot of hard coded #ifdefs scattered throughout
> the code base because people knew that the OS would only ever get built
> for one particular target.
>
> Well, fortunately that has changed. People are now building a single
> Linux binary for 10000 different targets. It was quite a lot of effort
> to get to that point, but it allows for much better scaling of manpower.
>
> I see a similar trend happening in firmware land. Take a look at André
> Przywara's presentation at FOSDEM. For usability reasons there is a
> certain desire to cover more than just a single target platform with a
> single binary.
>
> So while I agree that writing edk2 code is painful and writing Linux
> code is much less so, that's not the question.
>
> (Also, please don't call edk2 UEFI. There is so much in the UEFI spec
> and most people really don't care about most of the driver bits. You can
> use U-Boot just fine as UEFI provider and in fact you could even use
> Linux as UEFI provider with an appropriate user space that implements
> the services)
>
> >> Does that same kernel run on all the 10000 different types of servers I
> >> mentioned above?
> >
> > It runs on a huge range of servers, at this point every OCP server
> > we've tested, several proprietary servers from an unnamed company, the
> > Intel NUC, and chromebooks I've tried, as well as PC Engines boards.
>
> Is that the same source base or the exact same target binary? If it's
> the same target binary, the only way I can see this work is if you have
> runtime services in the form of a DSDT.
>
> > But, that said, the system needs to run part of coreboot or the
> > SEC/PEI part of UEFI; in the SEC/PEI case, that's a blob we will never
> > be allowed to replace, so it has to be assumed anyway :-(
>
> To be completely frank here, I don't see why someone as big as your
> employer can't replace whatever they like. Others seem to be able to?
>
> > And it relies on the early NON-runtime startup that the rom-based
> > firmware does. But our goal is to completely disable all UEFI runtime
> > services and SMM. runtime firmware services have proven to be too
> > large
> > a security problem to be allowed on x86.
>
> I think you'll be happy to hear that as part of the EBBR discussions we
> ended up with a UEFI ECR that will make it perfectly legal not to UEFI
> have runtime services:
>
>   https://pjones.fedorapeople.org/rt-unsupported-ecr-0.txt
>
> Though I perfectly consider UEFI RTS not the worst part of this puzzle,
> since they run in the same privilege level and they are only ever called
> by the OS.
>
> >> At least here we do agree (mostly) :).
> >
> > Well, TBH, I think your vision will probably be the one that will be
> > used, whether I like it or not :-)
>
> I'm not sure I have a conclusive vision yet :).
>
> > Looking forward to seeing you at FOSDEM!
>
> Same here!
>
>
> Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Mon, Jan 28, 2019 at 8:18 PM ron minnich <rminnich@gmail.com> wrote:

> That said, RISCV will have the SBI, and there is no getting around it
> for certain purposes, but there's no reason to encourage growth.

RISC-V is stated to be founded on "learning from the mistakes of the
past".  we're seeing empirical evidence that contradicts that
statement.  the problem is: the position of the proprietary companies
who seek to create secret firmware is quite reasonable.  there are a
number aspects, which should not be confused:

(1) the [false, arrogant] belief in "security through obscurity".
this is the belief that if the details of a security algorithm are
kept secret, that nobody will "work it out".  decades of evidence to
the contrary do not seem to be getting through their thick heads.

(2) the [unfortunately reasonable yet unethical] position that it is
only through early boot that "trust" may be provided - and by trust i
mean that the company that *deploys* the processor can "trust" that
there is an unbreakable chain of DRM which prevents and prohibits
tampering.  [i do not mean that the *users* can trust that their
rights, privacy and freedom are protected]

(3) the [reasonable] position that proprietary early boot additions to
RISC-V really do not need to be published (and would result in the
horrendous proliferation of customised early boot firmware
modifications noted eariler in the discussion), and that furthermore
in many instances the company *cannot release them anyway*... because
they didn't write them, they only *licensed* them.

examples of type (3) include Mediatek and other 2G/3G/LTE and WIFI
companies that typically have shared-memory embedded DSPs, or other
solutions that involve *third party* real-time Operating Systems on
which they base the software that runs the WIFI or 2G/3G/LTE service.

it gets even more complex when the FCC goes and fucks things up - and
you get idiotic people *in the free software community* supporting the
FCC in its consultation to lock-down WIFI firmware, as happened a
couple of years ago.

the reason i mention the FCC in this context is because even if the
full source code of WIFI or 2G/3G/LTE firmware running on such hybrid
systems were made available under libre licenses, whilst compilng and
installing binaries based around the source it would be a criminal
offense for people to actually *use* the result binaries based around
it... unless they paid the USD $50,000 fees to the FCC to have them
re-certified.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Bruce Hoult]

On Mon, Jan 28, 2019 at 11:40 AM ron minnich <rminnich@gmail.com> wrote:
> Short form: if the PMP makes it impossible to measure, disable and
> replace firmware from the kernel, then PMP is a bug, not a feature.

I disagree.

The owner/user should be able to change the SBI, perhaps by booting
into a special mode. The kernel in a system running normally shouldn't
be able to.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Mon, Jan 28, 2019 at 11:22 PM Bruce Hoult <brucehoult@sifive.com> wrote:

> On Mon, Jan 28, 2019 at 11:40 AM ron minnich <rminnich@gmail.com> wrote:
> > Short form: if the PMP makes it impossible to measure, disable and
> > replace firmware from the kernel, then PMP is a bug, not a feature.
>
> I disagree.
>
> The owner/user should be able to change the SBI, perhaps by booting
> into a special mode.

 ah, we have a bit of cross-over.  the problem is that there is a
financial disincentive to add such modes to all types of products.

 take an example: a DRM-locking mechanism endorsed and lobbied by the
Mafia Picture Association of America (the MPAA).  they want the
bootloader locked, so that the OS can be locked, so that the
applications can be locked, so that they can get their cut of revenues
and people cannot copy movies.

 if you are not familiar with how intrusive this really is, try buying
a portable USB DVD Drive and try to simply write data to it, on a
GNU/Linux system.  it will FAIL, but worse than that the DVD Drive
will *self-destruct* and never even read let alone write DVDs again,
and the reason it will fail is because there is a little-known
conspiracy between proprietary OS writers and the DVD manufacturers,
where if certain secret IDE commands are not sent to the DVD Drive
whilst it is writing, it *will* self-destruct

[in 2004 i actually had to take 3 such products back to Best Buy.
each one systematically failed, the moment i tried to use it to take
backups.  in the end i had to get an internal IDE drive]

 now... do you think that the Mafiaaa would be happy to learn of a
proposal to allow *users* to bypass the "security" that they lobbied
so hard for so long to have added into products?

 what do you think would happen to a company that tried to sell
product that had such "insecure" bypass mechanisms in it?  do you
believe that they would have *any* ODM clients take up their processor
as part of products?

 so unfortunately, with so much money involved in bringing processors
to market, "should" may be viewed by investors as "financially
irresponsible".  which makes me really annoyed, as the whole thing is
just so utterly unethical.

 l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

On Mon, Jan 28, 2019 at 3:22 PM Bruce Hoult <brucehoult@sifive.com> wrote:
>
> On Mon, Jan 28, 2019 at 11:40 AM ron minnich <rminnich@gmail.com> wrote:
> > Short form: if the PMP makes it impossible to measure, disable and
> > replace firmware from the kernel, then PMP is a bug, not a feature.
>
> I disagree.
>
> The owner/user should be able to change the SBI, perhaps by booting
> into a special mode. The kernel in a system running normally shouldn't
> be able to.


The nice thing about riscv is that we can both get what we want here :-)

I can tell you that security-oriented folks I'm working with much
prefer that the kernel be able to measure, selectively disable, or
replace firmware; and then set the PMP registers. The kernel should
drive the security, not firmware, because we have such ample evidence
that firmware is far less secure than kernels, in how it's written,
how it's built, and how it's deployed. In such a world, platforms that
do not allow this will be marked as not trustable.

The good news is that neither you nor I have to to dictate this for
everyone. There are going to be multiple SBI implementations and
firmware implementations for riscv, and we can see where this ends up.
One thing I can say for sure is there won't be just one.

ron

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <palmer@sifive.com> wrote:

> Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework.  With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode".  It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.

 ... and how is that to be achieved if the RISC-V Foundation
pathologically insists on secretive closed-doors discussions when it
comes to RISC-V specifications?

 it's time for the RISC-V Foundation to recognise that the ITU-style
closed doors practice is damaging the ecosystem by preventing people
from contributing.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

btw, w.r.t. carrying sbi with the kernel image.

When you get to a big enough world, and you get enough machines,
updating flash to update firmware runtime services is not guaranteed
to end well.
Flash just isn't that great and the less you depend on it the better.

So the idea of being able to fix an SBI problem by kexec'ing a kernel
that carries its own SBI is a very attractive idea. Anything that
reduces the role of persistent memory
for startup is a very attractive idea.

And this is why I believe an M mode that is changeable by the kernel
is a feature, not a bug: it let us do something we could not do
before.

That doesn't mean it is for every possible use; but the fact that you
can do it is great. You can't do that stuff on x86, for example, and
it's been a problem for 25 years now.
This is why I find riscv so attractive, it can free us from old thinking.


On Tue, Jan 29, 2019 at 4:06 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> > Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework.  With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode".  It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.
>
>  ... and how is that to be achieved if the RISC-V Foundation
> pathologically insists on secretive closed-doors discussions when it
> comes to RISC-V specifications?
>
>  it's time for the RISC-V Foundation to recognise that the ITU-style
> closed doors practice is damaging the ecosystem by preventing people
> from contributing.
>
> l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Bruce Hoult]

On Tue, Jan 29, 2019 at 4:06 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> > Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework.  With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode".  It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.
>
>  ... and how is that to be achieved if the RISC-V Foundation
> pathologically insists on secretive closed-doors discussions when it
> comes to RISC-V specifications?
>
>  it's time for the RISC-V Foundation to recognise that the ITU-style
> closed doors practice is damaging the ecosystem by preventing people
> from contributing.

There needs to be some slight barrier to entry, some commitment
needed, otherwise the process has a real danger of simply being
flooded by concern-trolls and time-wasters and never completing.
Designing things by discussion and consensus rather than simply having
a completed spec handed down from some expert is already
time-consuming enough.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Jan 30, 2019 at 12:50 AM Bruce Hoult <brucehoult@sifive.com> wrote:
>
> On Tue, Jan 29, 2019 at 4:06 PM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <palmer@sifive.com> wrote:
> >
> > > Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework.  With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode".  It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.
> >
> >  ... and how is that to be achieved if the RISC-V Foundation
> > pathologically insists on secretive closed-doors discussions when it
> > comes to RISC-V specifications?
> >
> >  it's time for the RISC-V Foundation to recognise that the ITU-style
> > closed doors practice is damaging the ecosystem by preventing people
> > from contributing.
>
> There needs to be some slight barrier to entry, some commitment
> needed, otherwise the process has a real danger of simply being
> flooded by concern-trolls and time-wasters and never completing.

 it's a legitimate concern, that i've witnessed from a couple of
"open" projects.  one of them was the mozilla "B2G" initiative, which
was flooded with top-postings of wannabe security "contributors" with
zero actual security experience, that drowned out legitimate security
analysis from "outsiders".

 it turned out in that particular case that it was well-known (for
over a decade) that there was a "core" team, who had absolutely no
intention whatsoever of listening to "outsider" constructive feedback,
regardless of consequences (including severe security design flaws).

 the "public discussion" was therefore preettty much pointless, and a
political sop.  it served a purpose of providing a bike-shed magnet so
that the "real" discussion by the "core team" could take place in
secret.

 ... guess what?  the project failed.

> Designing things by discussion and consensus rather than simply having
> a completed spec handed down from some expert is already
> time-consuming enough.

 it is... and that's just something that has to be accepted.  in open
(unregulated) discussions, what i find tends to happen is as follows:

 * time-wasters - those people not actually committed to the *genuine*
process of achieving the defined goal - tend to fall away through a
process of attrition.  over time, they simply don't get traction
(attention) and, through lack of long-term committment, they simply...
give up.

 * a *small* number of pathologically / psychologically disturbed
people, after a *long* and very very patient repetition of
non-confrontational hints from a large enough group, *eventually* get
the message and also give up.

which leaves behind a core of dedicated people who are *actually*
committed to the goal.  where it gets complicated is if the goal has
not been clearly defined, there is conflict and confusion,
proportional to the number of contributors.

the bottom line is: people have to be *really* dedicated to want to
contribute in this extremely technical field.  those people that are
not so motivated and not sufficiently technically competent become,
over time, quite easy to empirically identify.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Samuel Falvo II]

On Mon, Jan 28, 2019 at 7:48 PM Paul Miranda <paulcmiranda@gmail.com> wrote:
> I don't know enough about the rest of this thread to comment intelligently, but I'm curious what you advocate with respect to PMP?
> I believe it has usefulness in allowing M mode code to protect it from itself. Is your only concern that it may be used by ROM code that is not replaceable?
> It's definitely not the first protection scheme I've seen that uses lock bits.

If I understand Ron's emails correctly, he already indicated his
experience with such systems, and is basing his dislike of PMP
expressly on that experience.  It seems history records this feature
being abused rather profusely.

-- 
Samuel A. Falvo II

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

On Mon, Jan 28, 2019 at 7:48 PM Paul Miranda <paulcmiranda@gmail.com> wrote:
>

> I don't know enough about the rest of this thread to comment intelligently, but I'm curious what you advocate with respect to PMP?
> I believe it has usefulness in allowing M mode code to protect it from itself. Is your only concern that it may be used by ROM code that is not replaceable?

The rule is that measures taken by firmware to protect itself tend to
degrade overall security. We have ample evidence of this effect.

If firmware can protect it itself from the kernel, it's already
running at a higher privilege, and the history of firmware security
shows that is a poor practice. The last two years have shown it quite
a bit.
If the kernel wishes to lock down firmware from the kernel there are
already lots of ways to do that.

Sure, we do lockdown bits. That does not mean they're a good idea as
currently practiced.

ron

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Benjamin Herrenschmidt]

On Mon, 2019-01-28 at 11:40 -0800, ron minnich wrote:

   .../...

 (snip a very well written description of issues I fully agree with)

> I understand the motivation to fit a new architecture into old
> firmware clothes. It's just that the clothes are motheaten and out of
> style and never looked good when new. We're going to need to have an
> escape hatch for organizations looking for newer, better ways of doing
> things.
> 
> One possible way out at some point might be to define an SBI interface
> and operating mode that is responsive to concerns about firmware
> security, and avoiding the mistakes of the past. This does mean that
> there will not be "one SBI", which in turn means different kernel
> configurations, but I don't see much option. The concept of a "single
> SBI" was always going to be hard, and I expect at this point it will
> never happen.

IMHO, something like SBI has value when seen from the perspective of
providing a thin abstraction enabling existing OS binaries to run on
newer/different systems *as a fallback*. This should be done with the
clear intent and guidance that ultimately, the OS is meant to grow
native handling for those cases and platforms.

Cheers,
Ben.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Luís Marques]

On Tue, Feb 5, 2019 at 10:30 PM Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> IMHO, something like SBI has value when seen from the perspective of
> providing a thin abstraction enabling existing OS binaries to run on
> newer/different systems *as a fallback*. This should be done with the
> clear intent and guidance that ultimately, the OS is meant to grow
> native handling for those cases and platforms.

I like the idea of it being a fallback (and thus something that can be
replaced or complemented at runtime by the kernel, or even be absent
when the kernel has full knowledge of the exact hardware details).
That also meshes well with the goal of it being a fairly minimal
abstraction. It's not clear to me that the current design path will
take us there, unless this becomes a well reiterated goal, and the
implementation decision are made in alignment with that goal.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[ron minnich]

While I respect the tremendous amount of work the OpenSBI authors have
done, I agree with Benjamin and Luis.

There is a further issue that occurred to me doing their excellent
FOSDEM talk, which is that nowhere in this has any kind of verified
boot scenario been discussed, and if you don't get that thinking in
from the start it is very hard to wedge it in later.

I think we should consider the OpenSBI in its current state a starting
point for figuring out what we need to do.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Damien Le Moal]

On 2019/02/06 16:03, ron minnich wrote:
> While I respect the tremendous amount of work the OpenSBI authors have
> done, I agree with Benjamin and Luis.
> 
> There is a further issue that occurred to me doing their excellent
> FOSDEM talk, which is that nowhere in this has any kind of verified
> boot scenario been discussed, and if you don't get that thinking in
> from the start it is very hard to wedge it in later.
> 
> I think we should consider the OpenSBI in its current state a starting
> point for figuring out what we need to do.
> 

And this is exactly why we wanted OpenSBI released as soon as possible, before
even going further with cleaner specification documents for standardizing new
SBI calls beyond the currently defined legacy calls.

OpenSBI as it is now is indeed a starting point, a base we can use to explore
different design directions and implementations of RISC-V SBI interface, or its
lack for direct M-mode boot cases for application software (OSes) with full
support of a known platform.

Going forward, PMP and other security related features will need to be
considered and addressed and we hope that OpenSBI can also be used as a
reference implementation for any such early setup that the platform or OS may need.

There is still much to discuss, prototype and decide. OpenSBI will help in this
process providing an open reference implementation for all to see.

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Paul Walmsley]

On Tue, 5 Feb 2019, ron minnich wrote:

> While I respect the tremendous amount of work the OpenSBI authors have
> done, I agree with Benjamin and Luis.

There are a few key points that seem to be getting lost in this 
discussion:

1. OpenSBI is a sample implementation of the SBI interface, and is not the 
SBI standard itself

2. It is optional to implement the SBI, and it's likely that only certain 
types of platforms will do so

3. OpenSBI, from my point of view, consists of two distinct components:
	a. libraries that can be used as reference implementations by 
	   other early boot firmware; and
	b. sample early boot firmware that replaces riscv-pk

As far as I can tell, as long as the platform specification standards are 
written correctly, there's no conflict between SBI-based platforms and 
SBI-less platforms.

> There is a further issue that occurred to me doing their excellent
> FOSDEM talk, which is that nowhere in this has any kind of verified
> boot scenario been discussed, and if you don't get that thinking in
> from the start it is very hard to wedge it in later.

Verified boot seems almost completely orthogonal to OpenSBI's library 
implementation (3a, above).  U-boot, or Grub, or Coreboot, could reuse the 
OpenSBI libraries, but not the OpenSBI early boot firmware.  Then those 
other bootloaders can implement whatever verified/trusted/secure boot 
approach that they wish.

As 3b mentions above, the OpenSBI repository also contains sample early 
boot firmware.  That part of OpenSBI would clearly need to be modified to 
support some sort of verified boot.  However, no one to my knowledge is 
proposing to make the OpenSBI sample early boot firmware a RISC-V 
standard.  That part of OpenSBL is just a sample first-stage bootloader 
implementation - the same way that U-boot SPL or Coreboot romstage are 
sample first-stage bootloader implementations.

...

I personally am excited to finally be able to use U-boot's rich 
commandline interface and device drivers without needing to have riscv-pk 
(aka BBL) involved.  Those who are not doing active RISC-V Linux 
development may not be aware that the use of riscv-pk made it very 
difficult to use upstream-focused Linux DT data.  Even though I might have 
slightly different preferences for the current boot flow, their work 
removes a major obstacle from RISC-V Linux upstream development, and is a 
big step forward.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

RE: [sw-dev] SBI extension proposal v2

[Anup Patel]

> -----Original Message-----
> From: linux-riscv [mailto:linux-riscv-bounces@lists.infradead.org] On Behalf
> Of Paul Walmsley
> Sent: Thursday, February 7, 2019 9:27 AM
> To: ron minnich <rminnich@gmail.com>
> Cc: mark.rutland@arm.com; Christoph Hellwig <hch@infradead.org>;
> Damien Le Moal <Damien.LeMoal@wdc.com>; Olof Johansson
> <olof.johansson@gmail.com>; alankao@andestech.com;
> abner.chang@hpe.com; Luís Marques <luismarques@lowrisc.org>; Anup
> Patel <anup@brainfault.org>; Palmer Dabbelt <palmer@sifive.com>;
> Alexander Graf <agraf@suse.de>; zong@andestech.com; Atish Patra
> <Atish.Patra@wdc.com>; sw-dev@groups.riscv.org; Paul Walmsley
> <paul.walmsley@sifive.com>; Benjamin Herrenschmidt
> <benh@kernel.crashing.org>; mick@ics.forth.gr; Alistair Francis
> <Alistair.Francis@wdc.com>; Luke Kenneth Casson Leighton <lkcl@lkcl.net>;
> linux-riscv@lists.infradead.org; Andrew Waterman <andrew@sifive.com>
> Subject: Re: [sw-dev] SBI extension proposal v2
> 
> On Tue, 5 Feb 2019, ron minnich wrote:
> 
> > While I respect the tremendous amount of work the OpenSBI authors have
> > done, I agree with Benjamin and Luis.
> 
> There are a few key points that seem to be getting lost in this
> discussion:
> 
> 1. OpenSBI is a sample implementation of the SBI interface, and is not the SBI
> standard itself
> 
> 2. It is optional to implement the SBI, and it's likely that only certain types of
> platforms will do so
> 
> 3. OpenSBI, from my point of view, consists of two distinct components:
> 	a. libraries that can be used as reference implementations by
> 	   other early boot firmware; and
> 	b. sample early boot firmware that replaces riscv-pk

I would like to clarify that reference firmwares provided by OpenSBI
only provide RUNTIME services (i.e. handle SBI calls and M-mode traps)
so they are not early boot firmware.

The OpenSBI reference firmwares are not suitable to be used as ROM
firmware (e.g. ZSBL) or LOADER (e.g. FSBL) firmware. They are only
RUNTIME firmwares designed to replace BBL (riscv-pk).

Further, it is not mandatory to use OpenSBI reference firmwares as-is
and HW vendors can always create their own RUNTIME firmware (probably
link it to OpenSBI library).

> 
> As far as I can tell, as long as the platform specification standards are written
> correctly, there's no conflict between SBI-based platforms and SBI-less
> platforms.
> 
> > There is a further issue that occurred to me doing their excellent
> > FOSDEM talk, which is that nowhere in this has any kind of verified
> > boot scenario been discussed, and if you don't get that thinking in
> > from the start it is very hard to wedge it in later.
> 
> Verified boot seems almost completely orthogonal to OpenSBI's library
> implementation (3a, above).  U-boot, or Grub, or Coreboot, could reuse the
> OpenSBI libraries, but not the OpenSBI early boot firmware.  Then those
> other bootloaders can implement whatever verified/trusted/secure boot
> approach that they wish.
> 
> As 3b mentions above, the OpenSBI repository also contains sample early
> boot firmware.  That part of OpenSBI would clearly need to be modified to
> support some sort of verified boot.  However, no one to my knowledge is
> proposing to make the OpenSBI sample early boot firmware a RISC-V
> standard.  That part of OpenSBL is just a sample first-stage bootloader
> implementation - the same way that U-boot SPL or Coreboot romstage are
> sample first-stage bootloader implementations.
> 
> ...
> 
> I personally am excited to finally be able to use U-boot's rich commandline
> interface and device drivers without needing to have riscv-pk (aka BBL)
> involved.  Those who are not doing active RISC-V Linux development may not
> be aware that the use of riscv-pk made it very difficult to use upstream-
> focused Linux DT data.  Even though I might have slightly different
> preferences for the current boot flow, their work removes a major obstacle
> from RISC-V Linux upstream development, and is a big step forward.
> 
> 

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Anup Patel]

(Sorry for spamming, my previous reply got rejected by googlegroups).

On Thu, Feb 7, 2019 at 9:26 AM Paul Walmsley <paul.walmsley@sifive.com> wrote:
>
> On Tue, 5 Feb 2019, ron minnich wrote:
>
> > While I respect the tremendous amount of work the OpenSBI authors have
> > done, I agree with Benjamin and Luis.
>
> There are a few key points that seem to be getting lost in this
> discussion:
>
> 1. OpenSBI is a sample implementation of the SBI interface, and is not the
> SBI standard itself
>
> 2. It is optional to implement the SBI, and it's likely that only certain
> types of platforms will do so
>
> 3. OpenSBI, from my point of view, consists of two distinct components:
>         a. libraries that can be used as reference implementations by
>            other early boot firmware; and
>         b. sample early boot firmware that replaces riscv-pk

I would like to clarify that reference firmwares provided by OpenSBI
only provide RUNTIME services (i.e. handle SBI calls and M-mode traps)
so they are not early boot firmware.

The OpenSBI reference firmwares are not suitable to be used as ROM
firmware (e.g. ZSBL) or LOADER (e.g. FSBL) firmware. They are only
RUNTIME firmwares designed to replace BBL.

Further, it is not mandatory to use OpenSBI reference firmwares as-is
and HW vendors can simply create their own RUNTIME firmware (
probably link it o OpenSBI library).

>
> As far as I can tell, as long as the platform specification standards are
> written correctly, there's no conflict between SBI-based platforms and
> SBI-less platforms.
>
> > There is a further issue that occurred to me doing their excellent
> > FOSDEM talk, which is that nowhere in this has any kind of verified
> > boot scenario been discussed, and if you don't get that thinking in
> > from the start it is very hard to wedge it in later.
>
> Verified boot seems almost completely orthogonal to OpenSBI's library
> implementation (3a, above).  U-boot, or Grub, or Coreboot, could reuse the
> OpenSBI libraries, but not the OpenSBI early boot firmware.  Then those
> other bootloaders can implement whatever verified/trusted/secure boot
> approach that they wish.
>
> As 3b mentions above, the OpenSBI repository also contains sample early
> boot firmware.  That part of OpenSBI would clearly need to be modified to
> support some sort of verified boot.  However, no one to my knowledge is
> proposing to make the OpenSBI sample early boot firmware a RISC-V
> standard.  That part of OpenSBL is just a sample first-stage bootloader
> implementation - the same way that U-boot SPL or Coreboot romstage are
> sample first-stage bootloader implementations.
>
> ...
>
> I personally am excited to finally be able to use U-boot's rich
> commandline interface and device drivers without needing to have riscv-pk
> (aka BBL) involved.  Those who are not doing active RISC-V Linux
> development may not be aware that the use of riscv-pk made it very
> difficult to use upstream-focused Linux DT data.  Even though I might have
> slightly different preferences for the current boot flow, their work
> removes a major obstacle from RISC-V Linux upstream development, and is a
> big step forward.
>
>
> - Paul

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] SBI extension proposal v2

[Palmer Dabbelt]

On Sat, 01 Dec 2018 22:18:54 PST (-0800), benh@kernel.crashing.org wrote:
> On Sat, 2018-11-10 at 19:58 -0800, Atish Patra wrote:
>>
>> I think the larger picture might have lost somewhere because of the
>> verbosity of the proposal. The idea of adding vendor extension support
>> in SBI is to allow them provide a standard mechanism to facilitate this.
>> In absence of that, vendor might adopt different approaches to support
>> their feature leading a lot of chaos. Vendors can not go and add
>> anything in the Linux kernel(just a example, SBI is still OS agnostic)
>> as well.
>
> The concept of vendor extensions to a userspace ISA is so fundamentally
> broken to begin with, this FW proposal verges on utter insanity to be
> honest.
>
> Calling FW for things so deeply ingrained in the kernel such as context
> swithes, isn't going to fly. The performance will be ridiculously bad,
> among other things.
>
> If Risc-V wants to avoid fragmentation, it should simply keep a firmer
> reign in what is allowed in an implementation and keep a lid on such
> horrid ideas as vendor specific userspace ISA extensions.

Right now nobody with a Linux-capable RISC-V core has vendor-specific stateful 
extensions.  The plan is to avoid implementing any of this and convince people 
to avoid building them, but since the ISA allows for these we do need an out.  
I'd prefer this to forcing people to fork the kernel.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-10 17:48, Luke Kenneth Casson Leighton ??????:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????:
>> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>> > wrote:
>> >
>> >> ## Conclusion
>> >> This proposal is far from perfect and absolutely any suggestion is
>> >> welcome. Obviously, there are many other functionalities that can be
>> >> added to this proposal. However, I just wanted to start with something
>> >> that is an incremental change at best to kick off the discussion. The
>> >> aim here is to initiate a discussion that can lead to a robust SBI
>> >> specification.
>> >
>> >  very cool, atish.
>> >
>> >  i would very much like to see the optional addition of multiple
>> > serial lines, by adding a getchar and putchar function that takes just
>> > one extra argument: the serial line index.
>> >
>> >  there are a lot of different uses to which mult-serial lines may be
>> > put:
>> >
>> >  * boot message separation from console login
>> >  * boot management separation from other purposes (u-boot/coreboot)
>> >  * virtual /dev/ttyS0-3
>> >  * clean UPS reporting and management
>> >  * remote virtual machine power management (power-on / off)
>> >  * simple bog-standard multiple virtual login consoles
>> >  * separation of debug messages (stdout/stderr) to ease debugging and
>> > development
>> >  * remote and virtual OpenOCD and kernel debugging without disrupting
>> > the main serial console
>> >  * PPP serial links.
>> >
>> > this latter is one that i am particularly interested in, as i would
>> > like to be able to boot a full GNU/Linux OS on spike, given the lower
>> > barrier to entry in making modifications and experimenting with spike
>> > than it is with qemu.
>> >
>> >  if spike were able, through a multi-serial SBI interface, to have a
>> > PPP serial line, it would be possible to run a root NFS (or other
>> > network block device) without having to sacrifice console access.  it
>> > would be possible to create an initramfs from a lower-capability
>> > system like buildroot, containing PPP, enable it, and pivot-root out
>> > to a full stock GNU/Linux OS such as debian or fedora.
>> >
>> >  so there are huge benefits, reducing the development barrier to entry
>> > into RISC-V experimentation and debugging, and opening up a much wider
>> > range of capabilities and possibilities for machine and virtual system
>> > management.
>> >
>> > l.
>> 
>> 
>> The current SBI says that console_getchar/console_putchar are for the
>> debug
>> console but on Linux we use them for the main console on earlyprintk.
> 
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
> 

What does openocd has to do with the console ? Earlyprintk is output
only btw. The point here is that we need to update the documentation
because it's misleading, we don't have a debug console on the current
SBI, just a console.

>> I
>> think it's misleading and we should at least have an argument to chose
>> between the main console and an optional debug console, or rename
>> them to debug_console_getchar/debug_console_putchar and
>> main_console_getchar/
>> main_console_putchar.
> 
>  i initially thought of proposing that, however:
> 
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
> 
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
> 

I'm not in favor of main_console_getchar/debug_console_getchar etc, I
just wanted to point out that the API should be clear about what
console is to be used, not by using a serial line id but an id
that describes its usage.

>> However I don't think that argument should be the serial line. 
>> Different
>> vendors may use different serial lines for the main console / debug
>> console,
>> the caller doesn't know which serial line maps to which console, so 
>> the
>> SBI
>> should be more abstract and use something like a console id where e.g. 
>> 0
>> is
>> main console an 1 is debug.
> 
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
> 
> l.

Late in the game ? Who's game ? Is there any "standard" way out there
for mapping consoles to serial line indices ?

Regards,
Nick

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-10 17:48, Luke Kenneth Casson Leighton έγραψε:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> 
> wrote:
>> 
>> Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε:
>> > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com>
>> > wrote:
>> >
>> >> ## Conclusion
>> >> This proposal is far from perfect and absolutely any suggestion is
>> >> welcome. Obviously, there are many other functionalities that can be
>> >> added to this proposal. However, I just wanted to start with something
>> >> that is an incremental change at best to kick off the discussion. The
>> >> aim here is to initiate a discussion that can lead to a robust SBI
>> >> specification.
>> >
>> >  very cool, atish.
>> >
>> >  i would very much like to see the optional addition of multiple
>> > serial lines, by adding a getchar and putchar function that takes just
>> > one extra argument: the serial line index.
>> >
>> >  there are a lot of different uses to which mult-serial lines may be
>> > put:
>> >
>> >  * boot message separation from console login
>> >  * boot management separation from other purposes (u-boot/coreboot)
>> >  * virtual /dev/ttyS0-3
>> >  * clean UPS reporting and management
>> >  * remote virtual machine power management (power-on / off)
>> >  * simple bog-standard multiple virtual login consoles
>> >  * separation of debug messages (stdout/stderr) to ease debugging and
>> > development
>> >  * remote and virtual OpenOCD and kernel debugging without disrupting
>> > the main serial console
>> >  * PPP serial links.
>> >
>> > this latter is one that i am particularly interested in, as i would
>> > like to be able to boot a full GNU/Linux OS on spike, given the lower
>> > barrier to entry in making modifications and experimenting with spike
>> > than it is with qemu.
>> >
>> >  if spike were able, through a multi-serial SBI interface, to have a
>> > PPP serial line, it would be possible to run a root NFS (or other
>> > network block device) without having to sacrifice console access.  it
>> > would be possible to create an initramfs from a lower-capability
>> > system like buildroot, containing PPP, enable it, and pivot-root out
>> > to a full stock GNU/Linux OS such as debian or fedora.
>> >
>> >  so there are huge benefits, reducing the development barrier to entry
>> > into RISC-V experimentation and debugging, and opening up a much wider
>> > range of capabilities and possibilities for machine and virtual system
>> > management.
>> >
>> > l.
>> 
>> 
>> The current SBI says that console_getchar/console_putchar are for the
>> debug
>> console but on Linux we use them for the main console on earlyprintk.
> 
>  ... yeah exactly.  and what if something goes wrong, you want to be
> able to interact over openocd without interfering with that
> earlyprintk, particularly during that critical first bringup phase of
> real-world silicon?
> 

What does openocd has to do with the console ? Earlyprintk is output
only btw. The point here is that we need to update the documentation
because it's misleading, we don't have a debug console on the current
SBI, just a console.

>> I
>> think it's misleading and we should at least have an argument to chose
>> between the main console and an optional debug console, or rename
>> them to debug_console_getchar/debug_console_putchar and
>> main_console_getchar/
>> main_console_putchar.
> 
>  i initially thought of proposing that, however:
> 
>  (1) the API already exists with "single console". it would therefore
> be disruptive to change that
> 
>  (2) if adding something called debug_console_{get/put}char, it might
> as well take advantage of the opportunity to be extended and made
> generic, and have the extra argument added
> 

I'm not in favor of main_console_getchar/debug_console_getchar etc, I
just wanted to point out that the API should be clear about what
console is to be used, not by using a serial line id but an id
that describes its usage.

>> However I don't think that argument should be the serial line. 
>> Different
>> vendors may use different serial lines for the main console / debug
>> console,
>> the caller doesn't know which serial line maps to which console, so 
>> the
>> SBI
>> should be more abstract and use something like a console id where e.g. 
>> 0
>> is
>> main console an 1 is debug.
> 
>  yes, it should [have]: my feeling is, it's a little late in the game
> given that it's almost certainly baked into pre-existing hardware, by
> now, so the next best thing is a new function call.
> 
> l.

Late in the game ? Who's game ? Is there any "standard" way out there
for mapping consoles to serial line indices ?

Regards,
Nick

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:45 PM Nick Kossifidis <mick@ics.forth.gr> wrote:

> >  yes, it should [have]: my feeling is, it's a little late in the game
> > given that it's almost certainly baked into pre-existing hardware, by
> > now, so the next best thing is a new function call.
> >
> > l.
>
> Late in the game ? Who's game ? Is there any "standard" way out there
> for mapping consoles to serial line indices ?

 any implementor that has put a SBI v1.0 into a boot ROM in production
silicon (or even has put it into a design that's already had USD $5m+
of engineering time and testing done), would be absolutely screwed by
changes to v1.0 SBI.

 if however... if a way could be found to negotiate v1.0 being as-is,
and v2.0 declaring that there was an extra argument? yeah that would
work.

 i don't mind either way: i just really need to not have to have the
financial burden of augmenting and maintaining special ports of half a
dozen applications including minicom.

l.

Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton]

On Sat, Nov 10, 2018 at 5:45 PM Nick Kossifidis <mick@ics.forth.gr> wrote:

> >  yes, it should [have]: my feeling is, it's a little late in the game
> > given that it's almost certainly baked into pre-existing hardware, by
> > now, so the next best thing is a new function call.
> >
> > l.
>
> Late in the game ? Who's game ? Is there any "standard" way out there
> for mapping consoles to serial line indices ?

 any implementor that has put a SBI v1.0 into a boot ROM in production
silicon (or even has put it into a design that's already had USD $5m+
of engineering time and testing done), would be absolutely screwed by
changes to v1.0 SBI.

 if however... if a way could be found to negotiate v1.0 being as-is,
and v2.0 declaring that there was an extra argument? yeah that would
work.

 i don't mind either way: i just really need to not have to have the
financial burden of augmenting and maintaining special ports of half a
dozen applications including minicom.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[David Abdurachmanov]

On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com> wrote:
>
[..]

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>    long value;
>    long error;
> };
> ```

[..]

> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)

A small nictpick, but could we have consistent typing/language in the document?
I see you use "long", and even mix "int" and "u32" in a single definition.

If I look into PSCI I see:
```
SMC32 uint32
SMC64 uint64
entry_point_address
```
which leaves less interpretation for my eyes. For example, "long" can be
32-bit or 64-bit long depending on a few things and thus easier to make
mistake interpreting the spec.

I would suggest to use (u)int32/(u)uint64/friends and something
similar to SMC{32,64}
if needed.

david

Re: [sw-dev] SBI extension proposal v2

[David Abdurachmanov]

On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com> wrote:
>
[..]

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>    long value;
>    long error;
> };
> ```

[..]

> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)

A small nictpick, but could we have consistent typing/language in the document?
I see you use "long", and even mix "int" and "u32" in a single definition.

If I look into PSCI I see:
```
SMC32 uint32
SMC64 uint64
entry_point_address
```
which leaves less interpretation for my eyes. For example, "long" can be
32-bit or 64-bit long depending on a few things and thus easier to make
mistake interpreting the spec.

I would suggest to use (u)int32/(u)uint64/friends and something
similar to SMC{32,64}
if needed.

david

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[sw-dev] SBI extension proposal v2

[Nick Kossifidis]

???? 2018-11-10 07:47, Andrew Waterman ??????:
> On Fri, Nov 9, 2018 at 9:37 PM David Abdurachmanov
> <david.abdurachmanov@gmail.com> wrote:
> 
>> On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com>
>> wrote:
>>> 
>> [..]
>> 
>>> 2. Every SBI function call may return the following structure
>>> ```
>>> struct valerr {
>>> long value;
>>> long error;
>>> };
>>> ```
>> 
>> [..]
>> 
>>> int sbi_hart_suspend(u32 state, unsigned long resume_entry,
>> unsigned
>>> long priv)
>> 
>> A small nictpick, but could we have consistent typing/language in
>> the document?
>> I see you use "long", and even mix "int" and "u32" in a single
>> definition.
>> 
>> If I look into PSCI I see:
>> ```
>> SMC32 uint32
>> SMC64 uint64
>> entry_point_address
>> ```
>> which leaves less interpretation for my eyes. For example, "long"
>> can be
>> 32-bit or 64-bit long depending on a few things and thus easier to
>> make
>> mistake interpreting the spec.
>> 
>> I would suggest to use (u)int32/(u)uint64/friends and something
>> similar to SMC{32,64}
>> if needed.
> 
> Note, however, that the same spec is meant to be used for both RV32
> and RV64 systems, so some degree of type parameterization is
> necessary.
> 
>> david

We should definitely use typed integers for clarity but there is no
issue on how the structs will be formatted since the current calling
convention provides a pointer to the struct (so it's type is void*)
and the numbers passed through the SBI are 32bit ints (u32) so they
fit on both 32, 64 and 128bit registers. As long as we stick with
this calling convention of passing pointers and 32bit ints, we
should be fine.

Re: [sw-dev] SBI extension proposal v2

[Nick Kossifidis]

Στις 2018-11-10 07:47, Andrew Waterman έγραψε:
> On Fri, Nov 9, 2018 at 9:37 PM David Abdurachmanov
> <david.abdurachmanov@gmail.com> wrote:
> 
>> On Sat, Nov 10, 2018 at 3:42 AM Atish Patra <atish.patra@wdc.com>
>> wrote:
>>> 
>> [..]
>> 
>>> 2. Every SBI function call may return the following structure
>>> ```
>>> struct valerr {
>>> long value;
>>> long error;
>>> };
>>> ```
>> 
>> [..]
>> 
>>> int sbi_hart_suspend(u32 state, unsigned long resume_entry,
>> unsigned
>>> long priv)
>> 
>> A small nictpick, but could we have consistent typing/language in
>> the document?
>> I see you use "long", and even mix "int" and "u32" in a single
>> definition.
>> 
>> If I look into PSCI I see:
>> ```
>> SMC32 uint32
>> SMC64 uint64
>> entry_point_address
>> ```
>> which leaves less interpretation for my eyes. For example, "long"
>> can be
>> 32-bit or 64-bit long depending on a few things and thus easier to
>> make
>> mistake interpreting the spec.
>> 
>> I would suggest to use (u)int32/(u)uint64/friends and something
>> similar to SMC{32,64}
>> if needed.
> 
> Note, however, that the same spec is meant to be used for both RV32
> and RV64 systems, so some degree of type parameterization is
> necessary.
> 
>> david

We should definitely use typed integers for clarity but there is no
issue on how the structs will be formatted since the current calling
convention provides a pointer to the struct (so it's type is void*)
and the numbers passed through the SBI are 32bit ints (u32) so they
fit on both 32, 64 and 128bit registers. As long as we stick with
this calling convention of passing pointers and 32bit ints, we
should be fine.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

SBI extension proposal v2

[Nick Kossifidis]

Hello Atish,

???? 2018-11-10 04:42, Atish Patra ??????:
> Hi,
> I have updated the proposal based on feedback received on previous
> version. This version has a better scalable SBI Function ID
> numbering scheme. I have adopted markdown formatting for github docs.
> 
> If you prefer a github interface, it's available here as well.
> 
> https://github.com/riscv/riscv-sbi-doc/pull/12
> 
> Looking forward to your feedback.
> 
> Regards,
> Atish
> ------------------------------------------------------------------------
> 
> ## Introduction:
> This is a proposal to make SBI a flexible and extensible interface.
> It is based on the foundation policy of RISC-V i.e. modularity and
> openness. The proposal tries to introduces very few new mandatory SBI
> Functions, that are absolutely required to maintain backward
> compatibility. Everything else is optional so that it remains an open
> standard yet robust.
> 
> The current RISC-V SBI only defines a few mandatory functions such as
> inter-processor interrupts (IPI) interface, reprogramming timer, serial
> console, and memory barrier instructions. The existing SBI 
> documentation
> can be found here [1]. Many important functionalities such as power
> management/cpu-hotplug are not yet defined due to difficulties in
> accommodating modifications without breaking the backward compatibility
> with the current interface.
> 
> The proposed design is inspired by Power State Coordination Interface
> (PSCI) from ARM world. However, it adds only two new mandatory SBI
> calls providing version information and supported Functions, unlike
> PSCI where a significant number of functions are mandatory. The
> version of the existing SBI will be defined as a minimum version(0.1)
> which will always be backward compatible. Similarly, any Linux kernel
> with a newer feature will fall back if an older version of SBI does
> not support the updated capabilities. Both the operating system and
> SEE can be implemented to be two way backward compatible.
> 

Let's remove any references to Linux, it can be misleading since
this is supposed to be used by every OS.

> ## SBI Calling Conventions (TODO)
> There are some suggestions[3] to distinguish between SBI function
> return value and SBI calling sequence return value. Here are the few
> possible discussed ideas.
> 
> 1. Return a single value, but values in the range {-511, -1} are
> considered errors, whereas return values in the range {0, 2^XLEN-512}
> are considered success.
> 

I'm thinking about compatibility between a 64bit firmware and a 32bit
supervisor and vice-versa. If we report back values that can't fit
within 32bits, this is going to break things.

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>   long value;
>   long error;
> };
> ```
> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
> used for function return values.
> 

This makes sense, however let's allow for this to be extensible,
there may be SBI calls that want to return something more, there
may also be SBI calls that are asynchronous so it's a good idea I
think to also include the function id there. Also please let's use
typed integers instead. How about something like this:

struct sbi_report {
  uint32_t status;
  uint32_t value;
  uint32_t function_id;
  uint8_t has_payload;
  uint16_t payload_size;
  /* 1 byte hole */
  void payload[];
};

> 3. Introduce an extra argument that can return error by reference.
> ```
> /* Returns the CPU that was started.
>  * @err indicates an error ID if one occurred, otherwise 0.
>  * @err can be NULL if no error detection is required.
> */
> int start_cpu(int cpu_num,..., Error *err);
> ```
> Both approaches (2 & 3) will work, but there will be two versions of
> existing SBI functions to maintain the compatibility.
> 

If we keep the first field of sbi_report as the status code then
3 is equivalent to 2. If you just want to get the status/error code
you cast the pointer to uint32_t* instead of struct sbi_report*.

My vote goes for (1 || 2 with the mods above), meaning that I
believe we should support both, 1 for simple functions that
just want to return a value and 2 for more complex functions
that want to also return a payload or that distinguish the
return value from an error code. Alternatively I'd go with
just 2 with the mods above, since it covers both cases.

> ## SBI Functions:
> 
> A SBI function is an individual feature that SBI interface provides to
> supervisor mode from machine mode. Each function ID is assigned as per
> below section.
> 

As I mentioned on the previous version of your proposal
I'd like to be able to call these functions from U and
HS/HU modes as well. I think having a limitation for
accessing M mode only from S mode is wrong.

> #### SBI Function ID numbering scheme:
> A Function Set is a group of SBI functions which collectively
> implement similar kind of feature/functionality. The function ID
> numbering scheme need to be scalable in the future. At the same time,
> function validation check should be as quick as possible. Keeping
> these two requirements in mind, a hybrid function ID scheme is
> proposed.
> 
> SBI Function ID is u32 type.
> 
> ```
> 31            24                        0
> -----------------------------------------
> |O|            |                        |
> -----------------------------------------
> Function Set   | Function Type          |
> ```
> Bit[31]    =  ID overflow bit
> 
> Bit[30:24] =  Function Set
> 
> Bit[23:0]  =  Function Type within Function Set
> 
> The Function set is Bits [31:24] describing both function set number
> and overflow bit. In the beginning, the overflow bit should be set to
> **zero** and the function Type per function set can be assigned by
> left shifting 1 bit at a time. The overflow bit can be set to one
> **only** when we need to allocate more than 24 functions per function
> set in future. Setting the overflow bit will indicate an integer
> function type scheme. Thus, there will more than enough function IDs
> available to use in the future. Refer appendix 1 for examples.
> 
> Here are few Function Sets for SBI v0.2:
> 
> | Function Set         | Value  | Description       |
> | -------------------  |:------:| 
> :--------------------------------------------|
> | Base Functions       | 0x00   | Base Functions mandatory for any SBI 
> version |
> | HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for
> per-Hart power management|
> | System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for
> system-level power management|
> | Vendor Functions     | 0x7f   | Vendor specific Functions|
> 
> N.B. There is a possibility that different vendors can choose to
> assign the same function numbers for different functionality. That's
> why vendor specific strings in Device Tree/ACPI or any other hardware
> description document can be used to verify if a specific Function
> belongs to the intended vendor or not.
> 
> # SBI Function List in both SBI v0.2 and v0.1
> 
> |Function Type              | Function Set      | ID(v0.2)     |ID 
> (v0.1)  |
> |---------------------------| 
> ------------------|:------------:|:---------:|
> | sbi_set_timer             | Base              | 0x00 000000  |0       
>    |
> | sbi_console_putchar       | Base              | 0x00 000001  |1       
>    |
> | sbi_console_getchar       | Base              | 0x00 000002  |2       
>    |
> | sbi_clear_ipi             | Base              | 0x00 000004  |3       
>    |
> | sbi_send_ipi              | Base              | 0x00 000008  |4       
>    |
> | sbi_remote_fence_i        | Base              | 0x00 000010  |5       
>    |
> | sbi_remote_sfence_vma     | Base              | 0x00 000020  |6       
>    |
> | sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7       
>    |
> | sbi_shutdown              | System PM         | 0x02 000000  |8       
>    |
> | sbi_system_reset          | System PM         | 0x02 000001  |-       
>    |
> | sbi_get_version           | Base              | 0x00 000080  |-       
>    |
> | sbi_get_function_mask     | Base              | 0x00 000100  |-       
>    |
> | sbi_get_function_count    | Base              | 0x00 000200  |-       
>    |
> | sbi_hart_up               | Hart PM           | 0x01 000000  |-       
>    |
> | sbi_hart_down             | Hart PM           | 0x01 000001  |-       
>    |
> | sbi_hart_suspend          | Hart PM           | 0x01 000002  |-       
>    |
> | sbi_hart_state            | Hart PM           | 0x01 000004  |-       
>    |
> 

While I agree with the concept of categorizing functions, I think the
implementation is a bit complicated. We can just have function id
ranges instead of wasting a byte for encoding a category within the
function id. Also this approach will be backwards compatible with the
function ids we already have on current SBI.

Encoding function sets and a bitmask for functions, along with
the overflow bit on the function id seems overly complicated to me
and I don't see what we gain from this. We are wasting bits for
sets that may have only a few functions and need to support
overflow for sets that are larger than 24 functions which is not
that much, especially if you take vendor sets into account.
I understand that you want this bitmask for reporting back the list
of available functions per set but this can be done differently. For
example we can use introduce a function called sbi_call_check(uint32_t
function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.

Also with regards to the DT/ACPI the hardware vendor doesn't always
imply firmware vendor. I think we should be more specific here.
Also needing a side channel to understand which vendor specific
function we are calling is suboptimal. We might want to call
a vendor specific SBI call for example before parsing DT or
ACPI.

I believe we should use GUIDs for vendor specific function calls
instead of function ids. Normally these are 128bit long (RFC 4122)
but we can get away with 64bits. Instead of allowing a range of
function ids for vendors, we can just specify one call to rule
them all, something like:

int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)

under the hood this can be an SBI call e.g. with fid 0x10000000 that
takes 3 arguments (already supported), with the pointer on the 3rd
argument to point to a struct with the vendor call arguments on
call, and a pointer contain a struct sbi_report on return.

> #### Function Description
> 
> This section describes every newly introduced(in v0.2) function in
> details. Please refer to [1] for any v0.1 functions.
> 
> ```
> u32 sbi_get_version(void):
> ```
> Returns the current SBI version implemented by the firmware.
> version: uint32: Bits[31:16] Major Version
>              Bits[15:0] Minor Version
> 
> The existing SBI version can be 0.1. The proposed version will be at 
> 0.2
> A different major version may indicate possible incompatible functions.
> A different minor version must be compatible with each other even if
> they have a higher number of features.
> 
> ```
> u32 sbi_get_function_mask(u32 ftype)
> ```
> Given a function set type, it returns a bitmask of all functions IDs
> that are implemented for that function set.
> 
> ```
> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long 
> count):
> ```
> 
> This is a **reserved** function that should only be used if overflow
> bit in SBI function ID is set.
> 
> Accepts a start_Function_id as an argument and returns if
> start_Function_id to (start_Function_id + count - 1) are supported or
> not.
> 
> A count can help in minimizing the number of the M-mode traps by
> checking a range of SBI functions together.
> 

As I mentioned above I thing this complicates things and forces a
suboptimal function id encoding. We can instead introduce something
like sbi_call_check() instead. As for the vendor calls, we can also
introduce:

int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);

Another reason I find sbi_vendor_call/sbi_vendor_call_check better
is because the function names follow the rest of the namespace scheme.
I'll come back to that later on.

> ```
> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
> long priv)
> ```
> Brings up "hartid" either during initial boot or after a sbi_hart_down
> SBI call.
> 
> "start" points to a runtime-specified address where a hart can enter
> into supervisor mode. This must be a physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)
> ```
> Suspends the calling hart to a particular power state. Suspended hart
> will automatically wake-up based on some wakeup events at resume_entry
> physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context. The SBI implementation must save a copy so that
> caller can reuse while restoring hart from suspend.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_down()
> ```
> It powers off the hart and will be used in cpu-hotplug.
> Only individual hart can remove itself from supervisor mode. It can be
> moved to normal state only by sbi_hart_up function.
> 
> Return the appropriate SBI error code.
> 
> ```
> u32 sbi_hart_state(unsigned long hartid)
> ```
> Returns the RISCV_POWER_STATE for a specific hartid. This will help 
> make
> kexec like functionality more robust.
> 

I still think that it would be better to have sbi_hart_set_state and
sbi_hart_get_state instead of having different calls for different
states but I guess it's a matter of taste. Could we at least
use sbi_hart_get_state instead of sbi_hart_state to be consistent
with the rest of the calls that contain get/set on their name ?

> ```
> void sbi_system_reset(u32 reset_type)
> ```
> Reset the entire system.
> 

Could we please rename sbi_shutdown to sbi_system_shutdown so that
it's consistent with the _system_ namespace/category ?

> ## Return error code Table:
> Here are the SBI return error codes defined.
> 
> | Error Type               | Value  |
> | -------------------------|:------:|
> |  SBI_ERR_SUCCESS         |  0     |
> |  SBI_ERR_FAILURE         | -1     |
> |  SBI_ERR_NOT_SUPPORTED   | -2     |
> |  SBI_ERR_INVALID_PARAM   | -3     |
> |  SBI_ERR_DENIED          | -4     |
> |  SBI_ERR_INVALID_ADDRESS | -5     |
> 
> 

Since success is not error, could we call them status codes or just
return codes instead ?

Thank you for your time and effort on this !

Regards,
Nick

Re: SBI extension proposal v2

[Nick Kossifidis]

Hello Atish,

Στις 2018-11-10 04:42, Atish Patra έγραψε:
> Hi,
> I have updated the proposal based on feedback received on previous
> version. This version has a better scalable SBI Function ID
> numbering scheme. I have adopted markdown formatting for github docs.
> 
> If you prefer a github interface, it's available here as well.
> 
> https://github.com/riscv/riscv-sbi-doc/pull/12
> 
> Looking forward to your feedback.
> 
> Regards,
> Atish
> ------------------------------------------------------------------------
> 
> ## Introduction:
> This is a proposal to make SBI a flexible and extensible interface.
> It is based on the foundation policy of RISC-V i.e. modularity and
> openness. The proposal tries to introduces very few new mandatory SBI
> Functions, that are absolutely required to maintain backward
> compatibility. Everything else is optional so that it remains an open
> standard yet robust.
> 
> The current RISC-V SBI only defines a few mandatory functions such as
> inter-processor interrupts (IPI) interface, reprogramming timer, serial
> console, and memory barrier instructions. The existing SBI 
> documentation
> can be found here [1]. Many important functionalities such as power
> management/cpu-hotplug are not yet defined due to difficulties in
> accommodating modifications without breaking the backward compatibility
> with the current interface.
> 
> The proposed design is inspired by Power State Coordination Interface
> (PSCI) from ARM world. However, it adds only two new mandatory SBI
> calls providing version information and supported Functions, unlike
> PSCI where a significant number of functions are mandatory. The
> version of the existing SBI will be defined as a minimum version(0.1)
> which will always be backward compatible. Similarly, any Linux kernel
> with a newer feature will fall back if an older version of SBI does
> not support the updated capabilities. Both the operating system and
> SEE can be implemented to be two way backward compatible.
> 

Let's remove any references to Linux, it can be misleading since
this is supposed to be used by every OS.

> ## SBI Calling Conventions (TODO)
> There are some suggestions[3] to distinguish between SBI function
> return value and SBI calling sequence return value. Here are the few
> possible discussed ideas.
> 
> 1. Return a single value, but values in the range {-511, -1} are
> considered errors, whereas return values in the range {0, 2^XLEN-512}
> are considered success.
> 

I'm thinking about compatibility between a 64bit firmware and a 32bit
supervisor and vice-versa. If we report back values that can't fit
within 32bits, this is going to break things.

> 2. Every SBI function call may return the following structure
> ```
> struct valerr {
>   long value;
>   long error;
> };
> ```
> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
> used for function return values.
> 

This makes sense, however let's allow for this to be extensible,
there may be SBI calls that want to return something more, there
may also be SBI calls that are asynchronous so it's a good idea I
think to also include the function id there. Also please let's use
typed integers instead. How about something like this:

struct sbi_report {
  uint32_t status;
  uint32_t value;
  uint32_t function_id;
  uint8_t has_payload;
  uint16_t payload_size;
  /* 1 byte hole */
  void payload[];
};

> 3. Introduce an extra argument that can return error by reference.
> ```
> /* Returns the CPU that was started.
>  * @err indicates an error ID if one occurred, otherwise 0.
>  * @err can be NULL if no error detection is required.
> */
> int start_cpu(int cpu_num,..., Error *err);
> ```
> Both approaches (2 & 3) will work, but there will be two versions of
> existing SBI functions to maintain the compatibility.
> 

If we keep the first field of sbi_report as the status code then
3 is equivalent to 2. If you just want to get the status/error code
you cast the pointer to uint32_t* instead of struct sbi_report*.

My vote goes for (1 || 2 with the mods above), meaning that I
believe we should support both, 1 for simple functions that
just want to return a value and 2 for more complex functions
that want to also return a payload or that distinguish the
return value from an error code. Alternatively I'd go with
just 2 with the mods above, since it covers both cases.

> ## SBI Functions:
> 
> A SBI function is an individual feature that SBI interface provides to
> supervisor mode from machine mode. Each function ID is assigned as per
> below section.
> 

As I mentioned on the previous version of your proposal
I'd like to be able to call these functions from U and
HS/HU modes as well. I think having a limitation for
accessing M mode only from S mode is wrong.

> #### SBI Function ID numbering scheme:
> A Function Set is a group of SBI functions which collectively
> implement similar kind of feature/functionality. The function ID
> numbering scheme need to be scalable in the future. At the same time,
> function validation check should be as quick as possible. Keeping
> these two requirements in mind, a hybrid function ID scheme is
> proposed.
> 
> SBI Function ID is u32 type.
> 
> ```
> 31            24                        0
> -----------------------------------------
> |O|            |                        |
> -----------------------------------------
> Function Set   | Function Type          |
> ```
> Bit[31]    =  ID overflow bit
> 
> Bit[30:24] =  Function Set
> 
> Bit[23:0]  =  Function Type within Function Set
> 
> The Function set is Bits [31:24] describing both function set number
> and overflow bit. In the beginning, the overflow bit should be set to
> **zero** and the function Type per function set can be assigned by
> left shifting 1 bit at a time. The overflow bit can be set to one
> **only** when we need to allocate more than 24 functions per function
> set in future. Setting the overflow bit will indicate an integer
> function type scheme. Thus, there will more than enough function IDs
> available to use in the future. Refer appendix 1 for examples.
> 
> Here are few Function Sets for SBI v0.2:
> 
> | Function Set         | Value  | Description       |
> | -------------------  |:------:| 
> :--------------------------------------------|
> | Base Functions       | 0x00   | Base Functions mandatory for any SBI 
> version |
> | HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for
> per-Hart power management|
> | System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for
> system-level power management|
> | Vendor Functions     | 0x7f   | Vendor specific Functions|
> 
> N.B. There is a possibility that different vendors can choose to
> assign the same function numbers for different functionality. That's
> why vendor specific strings in Device Tree/ACPI or any other hardware
> description document can be used to verify if a specific Function
> belongs to the intended vendor or not.
> 
> # SBI Function List in both SBI v0.2 and v0.1
> 
> |Function Type              | Function Set      | ID(v0.2)     |ID 
> (v0.1)  |
> |---------------------------| 
> ------------------|:------------:|:---------:|
> | sbi_set_timer             | Base              | 0x00 000000  |0       
>    |
> | sbi_console_putchar       | Base              | 0x00 000001  |1       
>    |
> | sbi_console_getchar       | Base              | 0x00 000002  |2       
>    |
> | sbi_clear_ipi             | Base              | 0x00 000004  |3       
>    |
> | sbi_send_ipi              | Base              | 0x00 000008  |4       
>    |
> | sbi_remote_fence_i        | Base              | 0x00 000010  |5       
>    |
> | sbi_remote_sfence_vma     | Base              | 0x00 000020  |6       
>    |
> | sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7       
>    |
> | sbi_shutdown              | System PM         | 0x02 000000  |8       
>    |
> | sbi_system_reset          | System PM         | 0x02 000001  |-       
>    |
> | sbi_get_version           | Base              | 0x00 000080  |-       
>    |
> | sbi_get_function_mask     | Base              | 0x00 000100  |-       
>    |
> | sbi_get_function_count    | Base              | 0x00 000200  |-       
>    |
> | sbi_hart_up               | Hart PM           | 0x01 000000  |-       
>    |
> | sbi_hart_down             | Hart PM           | 0x01 000001  |-       
>    |
> | sbi_hart_suspend          | Hart PM           | 0x01 000002  |-       
>    |
> | sbi_hart_state            | Hart PM           | 0x01 000004  |-       
>    |
> 

While I agree with the concept of categorizing functions, I think the
implementation is a bit complicated. We can just have function id
ranges instead of wasting a byte for encoding a category within the
function id. Also this approach will be backwards compatible with the
function ids we already have on current SBI.

Encoding function sets and a bitmask for functions, along with
the overflow bit on the function id seems overly complicated to me
and I don't see what we gain from this. We are wasting bits for
sets that may have only a few functions and need to support
overflow for sets that are larger than 24 functions which is not
that much, especially if you take vendor sets into account.
I understand that you want this bitmask for reporting back the list
of available functions per set but this can be done differently. For
example we can use introduce a function called sbi_call_check(uint32_t
function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.

Also with regards to the DT/ACPI the hardware vendor doesn't always
imply firmware vendor. I think we should be more specific here.
Also needing a side channel to understand which vendor specific
function we are calling is suboptimal. We might want to call
a vendor specific SBI call for example before parsing DT or
ACPI.

I believe we should use GUIDs for vendor specific function calls
instead of function ids. Normally these are 128bit long (RFC 4122)
but we can get away with 64bits. Instead of allowing a range of
function ids for vendors, we can just specify one call to rule
them all, something like:

int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)

under the hood this can be an SBI call e.g. with fid 0x10000000 that
takes 3 arguments (already supported), with the pointer on the 3rd
argument to point to a struct with the vendor call arguments on
call, and a pointer contain a struct sbi_report on return.

> #### Function Description
> 
> This section describes every newly introduced(in v0.2) function in
> details. Please refer to [1] for any v0.1 functions.
> 
> ```
> u32 sbi_get_version(void):
> ```
> Returns the current SBI version implemented by the firmware.
> version: uint32: Bits[31:16] Major Version
>              Bits[15:0] Minor Version
> 
> The existing SBI version can be 0.1. The proposed version will be at 
> 0.2
> A different major version may indicate possible incompatible functions.
> A different minor version must be compatible with each other even if
> they have a higher number of features.
> 
> ```
> u32 sbi_get_function_mask(u32 ftype)
> ```
> Given a function set type, it returns a bitmask of all functions IDs
> that are implemented for that function set.
> 
> ```
> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long 
> count):
> ```
> 
> This is a **reserved** function that should only be used if overflow
> bit in SBI function ID is set.
> 
> Accepts a start_Function_id as an argument and returns if
> start_Function_id to (start_Function_id + count - 1) are supported or
> not.
> 
> A count can help in minimizing the number of the M-mode traps by
> checking a range of SBI functions together.
> 

As I mentioned above I thing this complicates things and forces a
suboptimal function id encoding. We can instead introduce something
like sbi_call_check() instead. As for the vendor calls, we can also
introduce:

int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);

Another reason I find sbi_vendor_call/sbi_vendor_call_check better
is because the function names follow the rest of the namespace scheme.
I'll come back to that later on.

> ```
> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
> long priv)
> ```
> Brings up "hartid" either during initial boot or after a sbi_hart_down
> SBI call.
> 
> "start" points to a runtime-specified address where a hart can enter
> into supervisor mode. This must be a physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
> long priv)
> ```
> Suspends the calling hart to a particular power state. Suspended hart
> will automatically wake-up based on some wakeup events at resume_entry
> physical address.
> 
> "priv" is a private data that caller can use to pass information about
> execution context. The SBI implementation must save a copy so that
> caller can reuse while restoring hart from suspend.
> 
> Return the appropriate SBI error code.
> 
> ```
> int sbi_hart_down()
> ```
> It powers off the hart and will be used in cpu-hotplug.
> Only individual hart can remove itself from supervisor mode. It can be
> moved to normal state only by sbi_hart_up function.
> 
> Return the appropriate SBI error code.
> 
> ```
> u32 sbi_hart_state(unsigned long hartid)
> ```
> Returns the RISCV_POWER_STATE for a specific hartid. This will help 
> make
> kexec like functionality more robust.
> 

I still think that it would be better to have sbi_hart_set_state and
sbi_hart_get_state instead of having different calls for different
states but I guess it's a matter of taste. Could we at least
use sbi_hart_get_state instead of sbi_hart_state to be consistent
with the rest of the calls that contain get/set on their name ?

> ```
> void sbi_system_reset(u32 reset_type)
> ```
> Reset the entire system.
> 

Could we please rename sbi_shutdown to sbi_system_shutdown so that
it's consistent with the _system_ namespace/category ?

> ## Return error code Table:
> Here are the SBI return error codes defined.
> 
> | Error Type               | Value  |
> | -------------------------|:------:|
> |  SBI_ERR_SUCCESS         |  0     |
> |  SBI_ERR_FAILURE         | -1     |
> |  SBI_ERR_NOT_SUPPORTED   | -2     |
> |  SBI_ERR_INVALID_PARAM   | -3     |
> |  SBI_ERR_DENIED          | -4     |
> |  SBI_ERR_INVALID_ADDRESS | -5     |
> 
> 

Since success is not error, could we call them status codes or just
return codes instead ?

Thank you for your time and effort on this !

Regards,
Nick


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [sw-dev] Re: SBI extension proposal v2

[Atish Patra]

On 11/11/18 8:34 PM, Nick Kossifidis wrote:
> Hello Atish,
> 

Apologies for not responding to this earlier. It got lost in the email 
flood. Thank you for reminding about this yesterday.

> Στις 2018-11-10 04:42, Atish Patra έγραψε:
>> Hi,
>> I have updated the proposal based on feedback received on previous
>> version. This version has a better scalable SBI Function ID
>> numbering scheme. I have adopted markdown formatting for github docs.
>>
>> If you prefer a github interface, it's available here as well.
>>
>> https://github.com/riscv/riscv-sbi-doc/pull/12
>>
>> Looking forward to your feedback.
>>
>> Regards,
>> Atish
>> ------------------------------------------------------------------------
>>
>> ## Introduction:
>> This is a proposal to make SBI a flexible and extensible interface.
>> It is based on the foundation policy of RISC-V i.e. modularity and
>> openness. The proposal tries to introduces very few new mandatory SBI
>> Functions, that are absolutely required to maintain backward
>> compatibility. Everything else is optional so that it remains an open
>> standard yet robust.
>>
>> The current RISC-V SBI only defines a few mandatory functions such as
>> inter-processor interrupts (IPI) interface, reprogramming timer, serial
>> console, and memory barrier instructions. The existing SBI
>> documentation
>> can be found here [1]. Many important functionalities such as power
>> management/cpu-hotplug are not yet defined due to difficulties in
>> accommodating modifications without breaking the backward compatibility
>> with the current interface.
>>
>> The proposed design is inspired by Power State Coordination Interface
>> (PSCI) from ARM world. However, it adds only two new mandatory SBI
>> calls providing version information and supported Functions, unlike
>> PSCI where a significant number of functions are mandatory. The
>> version of the existing SBI will be defined as a minimum version(0.1)
>> which will always be backward compatible. Similarly, any Linux kernel
>> with a newer feature will fall back if an older version of SBI does
>> not support the updated capabilities. Both the operating system and
>> SEE can be implemented to be two way backward compatible.
>>
> 
> Let's remove any references to Linux, it can be misleading since
> this is supposed to be used by every OS.
> 

ACK.

>> ## SBI Calling Conventions (TODO)
>> There are some suggestions[3] to distinguish between SBI function
>> return value and SBI calling sequence return value. Here are the few
>> possible discussed ideas.
>>
>> 1. Return a single value, but values in the range {-511, -1} are
>> considered errors, whereas return values in the range {0, 2^XLEN-512}
>> are considered success.
>>
> 
> I'm thinking about compatibility between a 64bit firmware and a 32bit
> supervisor and vice-versa. If we report back values that can't fit
> within 32bits, this is going to break things.
>
Yeah. That's valid point. I think we can keep both value & error to be 
uint32_t. We can clearly define uint64_t for for RV64GC and uint32_t for 
RV32GC if any functions require a 64bit value as an argument/return value.

Note: That's not my preferred choice. But it can be done.

>> 2. Every SBI function call may return the following structure
>> ```
>> struct valerr {
>>    long value;
>>    long error;
>> };
>> ```
>> According to the RISC-V ABI spec[4], both a0 & a1 registers can be
>> used for function return values.
>>
> 
> This makes sense, however let's allow for this to be extensible,
> there may be SBI calls that want to return something more, there
> may also be SBI calls that are asynchronous so it's a good idea I
> think to also include the function id there. Also please let's use
> typed integers instead. How about something like this:
> 

ACK for typed integers.

> struct sbi_report {
>    uint32_t status;
>    uint32_t value;
>    uint32_t function_id;
>    uint8_t has_payload;
>    uint16_t payload_size;
>    /* 1 byte hole */
>    void payload[];
> };
IMHO, that's overkill for SBI. Between error and value, I think we can 
cover all the cases.

> 
>> 3. Introduce an extra argument that can return error by reference.
>> ```
>> /* Returns the CPU that was started.
>>   * @err indicates an error ID if one occurred, otherwise 0.
>>   * @err can be NULL if no error detection is required.
>> */
>> int start_cpu(int cpu_num,..., Error *err);
>> ```
>> Both approaches (2 & 3) will work, but there will be two versions of
>> existing SBI functions to maintain the compatibility.
>>
> 
> If we keep the first field of sbi_report as the status code then
> 3 is equivalent to 2. If you just want to get the status/error code
> you cast the pointer to uint32_t* instead of struct sbi_report*.
> 
> My vote goes for (1 || 2 with the mods above), meaning that I
> believe we should support both, 1 for simple functions that
> just want to return a value and 2 for more complex functions
> that want to also return a payload or that distinguish the
> return value from an error code. Alternatively I'd go with
> just 2 with the mods above, since it covers both cases.
> 

Yeah 2 seems to be the best choice. We had a longer discussion about 
this during Linux Plumbers as well. Here are the notes in case you are 
interested.

https://etherpad.openstack.org/p/RISC-V

>> ## SBI Functions:
>>
>> A SBI function is an individual feature that SBI interface provides to
>> supervisor mode from machine mode. Each function ID is assigned as per
>> below section.
>>
> 
> As I mentioned on the previous version of your proposal
> I'd like to be able to call these functions from U and
> HS/HU modes as well. I think having a limitation for
> accessing M mode only from S mode is wrong.
> 

I understand your concern. However, this part of the specification is 
based on what is defined on privileged spec. I would like to keep it 
consistent with privileged spec.

>> #### SBI Function ID numbering scheme:
>> A Function Set is a group of SBI functions which collectively
>> implement similar kind of feature/functionality. The function ID
>> numbering scheme need to be scalable in the future. At the same time,
>> function validation check should be as quick as possible. Keeping
>> these two requirements in mind, a hybrid function ID scheme is
>> proposed.
>>
>> SBI Function ID is u32 type.
>>
>> ```
>> 31            24                        0
>> -----------------------------------------
>> |O|            |                        |
>> -----------------------------------------
>> Function Set   | Function Type          |
>> ```
>> Bit[31]    =  ID overflow bit
>>
>> Bit[30:24] =  Function Set
>>
>> Bit[23:0]  =  Function Type within Function Set
>>
>> The Function set is Bits [31:24] describing both function set number
>> and overflow bit. In the beginning, the overflow bit should be set to
>> **zero** and the function Type per function set can be assigned by
>> left shifting 1 bit at a time. The overflow bit can be set to one
>> **only** when we need to allocate more than 24 functions per function
>> set in future. Setting the overflow bit will indicate an integer
>> function type scheme. Thus, there will more than enough function IDs
>> available to use in the future. Refer appendix 1 for examples.
>>
>> Here are few Function Sets for SBI v0.2:
>>
>> | Function Set         | Value  | Description       |
>> | -------------------  |:------:|
>> :--------------------------------------------|
>> | Base Functions       | 0x00   | Base Functions mandatory for any SBI
>> version |
>> | HART PM Functions    | 0x01   | Hart UP/Down/Suspend Functions for
>> per-Hart power management|
>> | System PM Functions  | 0x02   | System Shutdown/Reboot/Suspend for
>> system-level power management|
>> | Vendor Functions     | 0x7f   | Vendor specific Functions|
>>
>> N.B. There is a possibility that different vendors can choose to
>> assign the same function numbers for different functionality. That's
>> why vendor specific strings in Device Tree/ACPI or any other hardware
>> description document can be used to verify if a specific Function
>> belongs to the intended vendor or not.
>>
>> # SBI Function List in both SBI v0.2 and v0.1
>>
>> |Function Type              | Function Set      | ID(v0.2)     |ID
>> (v0.1)  |
>> |---------------------------|
>> ------------------|:------------:|:---------:|
>> | sbi_set_timer             | Base              | 0x00 000000  |0
>>     |
>> | sbi_console_putchar       | Base              | 0x00 000001  |1
>>     |
>> | sbi_console_getchar       | Base              | 0x00 000002  |2
>>     |
>> | sbi_clear_ipi             | Base              | 0x00 000004  |3
>>     |
>> | sbi_send_ipi              | Base              | 0x00 000008  |4
>>     |
>> | sbi_remote_fence_i        | Base              | 0x00 000010  |5
>>     |
>> | sbi_remote_sfence_vma     | Base              | 0x00 000020  |6
>>     |
>> | sbi_remote_sfence_vma_asid| Base              | 0x00 000040  |7
>>     |
>> | sbi_shutdown              | System PM         | 0x02 000000  |8
>>     |
>> | sbi_system_reset          | System PM         | 0x02 000001  |-
>>     |
>> | sbi_get_version           | Base              | 0x00 000080  |-
>>     |
>> | sbi_get_function_mask     | Base              | 0x00 000100  |-
>>     |
>> | sbi_get_function_count    | Base              | 0x00 000200  |-
>>     |
>> | sbi_hart_up               | Hart PM           | 0x01 000000  |-
>>     |
>> | sbi_hart_down             | Hart PM           | 0x01 000001  |-
>>     |
>> | sbi_hart_suspend          | Hart PM           | 0x01 000002  |-
>>     |
>> | sbi_hart_state            | Hart PM           | 0x01 000004  |-
>>     |
>>
> 
> While I agree with the concept of categorizing functions, I think the
> implementation is a bit complicated. We can just have function id
> ranges instead of wasting a byte for encoding a category within the
> function id. Also this approach will be backwards compatible with the
> function ids we already have on current SBI.
> 
> Encoding function sets and a bitmask for functions, along with
> the overflow bit on the function id seems overly complicated to me
> and I don't see what we gain from this. We are wasting bits for
> sets that may have only a few functions and need to support
> overflow for sets that are larger than 24 functions which is not
> that much, especially if you take vendor sets into account.
> I understand that you want this bitmask for reporting back the list
> of available functions per set but this can be done differently. For
> example we can use introduce a function called sbi_call_check(uint32_t
> function_id) and expect SBI_ERR_SUCCESS or SBI_ERR_NOT_SUPPORTED.
> 

Yeah. I had that in the first version. I will drop the above complicated 
scheme.

> Also with regards to the DT/ACPI the hardware vendor doesn't always
> imply firmware vendor. I think we should be more specific here.
> Also needing a side channel to understand which vendor specific
> function we are calling is suboptimal. We might want to call
> a vendor specific SBI call for example before parsing DT or
> ACPI.
> 
> I believe we should use GUIDs for vendor specific function calls
> instead of function ids. Normally these are 128bit long (RFC 4122)
> but we can get away with 64bits. Instead of allowing a range of
> function ids for vendors, we can just specify one call to rule
> them all, something like:
> 
> int sbi_vendor_call(uint32_t vfid_high, uint32_t vfid_low, void* arg)
> 
> under the hood this can be an SBI call e.g. with fid 0x10000000 that
> takes 3 arguments (already supported), with the pointer on the 3rd
> argument to point to a struct with the vendor call arguments on
> call, and a pointer contain a struct sbi_report on return.
> 

Thanks for your inputs. We can discuss these in details during vendor 
SBI extension proposal.

>> #### Function Description
>>
>> This section describes every newly introduced(in v0.2) function in
>> details. Please refer to [1] for any v0.1 functions.
>>
>> ```
>> u32 sbi_get_version(void):
>> ```
>> Returns the current SBI version implemented by the firmware.
>> version: uint32: Bits[31:16] Major Version
>>               Bits[15:0] Minor Version
>>
>> The existing SBI version can be 0.1. The proposed version will be at
>> 0.2
>> A different major version may indicate possible incompatible functions.
>> A different minor version must be compatible with each other even if
>> they have a higher number of features.
>>
>> ```
>> u32 sbi_get_function_mask(u32 ftype)
>> ```
>> Given a function set type, it returns a bitmask of all functions IDs
>> that are implemented for that function set.
>>
>> ```
>> u32 sbi_get_function_count(u32 ftype, u32 start_fid, unsigned long
>> count):
>> ```
>>
>> This is a **reserved** function that should only be used if overflow
>> bit in SBI function ID is set.
>>
>> Accepts a start_Function_id as an argument and returns if
>> start_Function_id to (start_Function_id + count - 1) are supported or
>> not.
>>
>> A count can help in minimizing the number of the M-mode traps by
>> checking a range of SBI functions together.
>>
> 
> As I mentioned above I thing this complicates things and forces a
> suboptimal function id encoding. We can instead introduce something
> like sbi_call_check() instead. As for the vendor calls, we can also
> introduce:
> 
> int sbi_vendor_call_check(uint32_t vfid_high, uint32_t vfid_low);
> 
> Another reason I find sbi_vendor_call/sbi_vendor_call_check better
> is because the function names follow the rest of the namespace scheme.
> I'll come back to that later on.
> 



>> ```
>> int sbi_hart_up(unsigned long hartid, unsigned long start, unsigned
>> long priv)
>> ```
>> Brings up "hartid" either during initial boot or after a sbi_hart_down
>> SBI call.
>>
>> "start" points to a runtime-specified address where a hart can enter
>> into supervisor mode. This must be a physical address.
>>
>> "priv" is a private data that caller can use to pass information about
>> execution context.
>>
>> Return the appropriate SBI error code.
>>
>> ```
>> int sbi_hart_suspend(u32 state, unsigned long resume_entry, unsigned
>> long priv)
>> ```
>> Suspends the calling hart to a particular power state. Suspended hart
>> will automatically wake-up based on some wakeup events at resume_entry
>> physical address.
>>
>> "priv" is a private data that caller can use to pass information about
>> execution context. The SBI implementation must save a copy so that
>> caller can reuse while restoring hart from suspend.
>>
>> Return the appropriate SBI error code.
>>
>> ```
>> int sbi_hart_down()
>> ```
>> It powers off the hart and will be used in cpu-hotplug.
>> Only individual hart can remove itself from supervisor mode. It can be
>> moved to normal state only by sbi_hart_up function.
>>
>> Return the appropriate SBI error code.
>>
>> ```
>> u32 sbi_hart_state(unsigned long hartid)
>> ```
>> Returns the RISCV_POWER_STATE for a specific hartid. This will help
>> make
>> kexec like functionality more robust.
>>
> 
> I still think that it would be better to have sbi_hart_set_state and
> sbi_hart_get_state instead of having different calls for different
> states but I guess it's a matter of taste. Could we at least
> use sbi_hart_get_state instead of sbi_hart_state to be consistent
> with the rest of the calls that contain get/set on their name ?
> 

ACK.

>> ```
>> void sbi_system_reset(u32 reset_type)
>> ```
>> Reset the entire system.
>>
> 
> Could we please rename sbi_shutdown to sbi_system_shutdown so that
> it's consistent with the _system_ namespace/category ?
> 

ACK. However, sbi_shutdown is already a part of legacy APIs. So it has 
to be supported that way.

The power management SBI extension, we will use the consistent naming.

>> ## Return error code Table:
>> Here are the SBI return error codes defined.
>>
>> | Error Type               | Value  |
>> | -------------------------|:------:|
>> |  SBI_ERR_SUCCESS         |  0     |
>> |  SBI_ERR_FAILURE         | -1     |
>> |  SBI_ERR_NOT_SUPPORTED   | -2     |
>> |  SBI_ERR_INVALID_PARAM   | -3     |
>> |  SBI_ERR_DENIED          | -4     |
>> |  SBI_ERR_INVALID_ADDRESS | -5     |
>>
>>
> 
> Since success is not error, could we call them status codes or just
> return codes instead ?
> 

Yup. Return code is ok.


Regards,
Atish
> Thank you for your time and effort on this !
> 
> Regards,
> Nick
> 



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv