On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens wrote:

Hi everyone,

To start off discussion about requirements that should go into the
platform spec, I propose a simple change to current software:

When entering S-mode for the first time, the a2 register should
contain the value 0x54414c5058494e55 ("UNIXPLAT").

The intention here is that software should be able to look for this
value and know that it has been booted in a Supervisor Execution
Environment that is compliant with the Unix-class platform spec. This
would distinguish both from old implementations that only support SBI
v0.1, but also possible future execution environments designed by
other groups.

For SBI version, supervisor systems should use "sbi_get_spec_version"
API to identify what is the SBI version of the SBI implementation. For
v0.1, the above call will return a -ve value indicating that this is a
v0.1.

That's how linux kernel currently detects the SBI version dynamically.

Jonathan

--
Regards,
Atish

On Tue, 2020-06-23 at 16:37 -0400, Jonathan Behrens wrote:

On Fri, Jun 19, 2020 at 5:42 PM Atish Patra <Atish.Patra@...>
wrote:

On Jun 19, 2020, at 1:26 PM, Jonathan Behrens <behrensj@...>
wrote:

Thanks for that clarification! It is good to know that SBI v0.1
implementations are consistent about returning negative values
for functions they don't recognize like sbi_get_spec_version.
This however doesn't work for environments which cannot or don't
want to implement the SBI at all (what value do you return to say
there is no SBI?)

Once RISC-V is more widely deployed, it is likely that there will
be more platform specs written by other committees, or even
groups entirely outside of the RISC-V foundation. They may not
want to require ecalls to detect capabilities, or might have
other constraints. Yet, developers will likely want to write
kernels that can boot across a range of these different
environments. This has certainly been the case on x86 where
there's lots of different bootloaders that each work with their
own conventions.

Yes. That’s a possibility. If I understand you correctly, you want
some identifier that let supervisor know that the M-mode
firmware is an SBI based one.

If that’s the only case, how about a DT property under /chosen node
instead of reserving a register for a fixed value.

The register value would also signal the other elements of this
platform spec are being followed. Notably including that a1 actually
points to a valid device tree. If we could count on a device tree
always being present then I agree that going the /chosen route would
be cleaner, but if a future third party standard decided to go with
ACPI tables or something instead then they may not be willing to
require a dummy device tree just to allow software to blindly
dereference a1.

For ACPI tables, a similar property can be added in the ACPI table.
We anyways have to add other run time properties to ACPI table as we do
currently for the device tree.

Jonathan

To give one case where this already seems to be coming up, Linux
can run in M-mode instead of S-mode but only if it is configured
that way at compile time. If Linux had a better way to know
whether there was firmware present, it might be able to use a
shared kernel binary for both cases.

Best,
Jonathan

On Wed, Jun 17, 2020 at 2:56 PM Atish Patra <Atish.Patra@...>
wrote:

On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens wrote:

Hi everyone,

To start off discussion about requirements that should go

into the

platform spec, I propose a simple change to current software:

When entering S-mode for the first time, the a2 register

should

contain the value 0x54414c5058494e55 ("UNIXPLAT").

The intention here is that software should be able to look

for this

value and know that it has been booted in a Supervisor

Execution

Environment that is compliant with the Unix-class platform

spec. This

would distinguish both from old implementations that only

support SBI

v0.1, but also possible future execution environments

designed by

other groups.

For SBI version, supervisor systems should use
"sbi_get_spec_version"
API to identify what is the SBI version of the SBI
implementation. For
v0.1, the above call will return a -ve value indicating that
this is a
v0.1.

That's how linux kernel currently detects the SBI version
dynamically.

Jonathan

--
Regards,
Atish

On Wed, 2020-06-24 at 13:04 -0400, Jonathan Behrens wrote:

But how will the booting OS know whether to look at ACPI tables or
the device tree? Wouldn't you need some register to indicate which
one is being used?

I am not sure how it will be implemented in RISC-V when we have ACPI.
However, this is process followed in ARM64[1]

ACPI tables are passed via UEFI system configuration table while DT
address will be passed in x0. Kernel tries to use DT first if ACPI is
not preferred choice from kernel commandline. If it fails to find a DT,
it will try to use ACPI table if exists.


[1] https://lwn.net/Articles/642050/

Jonathan

On Wed, Jun 24, 2020 at 11:18 AM Atish Patra via lists.riscv.org <
atish.patra=wdc.com@...> wrote:

On Tue, 2020-06-23 at 16:37 -0400, Jonathan Behrens wrote:

On Fri, Jun 19, 2020 at 5:42 PM Atish Patra <Atish.Patra@...>
wrote:

On Jun 19, 2020, at 1:26 PM, Jonathan Behrens <

behrensj@...>

wrote:

Thanks for that clarification! It is good to know that SBI

v0.1

implementations are consistent about returning negative

values

for functions they don't recognize like sbi_get_spec_version.
This however doesn't work for environments which cannot or

don't

want to implement the SBI at all (what value do you return to

say

there is no SBI?)

Once RISC-V is more widely deployed, it is likely that there

will

be more platform specs written by other committees, or even
groups entirely outside of the RISC-V foundation. They may

not

want to require ecalls to detect capabilities, or might have
other constraints. Yet, developers will likely want to write
kernels that can boot across a range of these different
environments. This has certainly been the case on x86 where
there's lots of different bootloaders that each work with

their

own conventions.

Yes. That’s a possibility. If I understand you correctly, you

want

some identifier that let supervisor know that the M-mode
firmware is an SBI based one.

If that’s the only case, how about a DT property under /chosen

node

instead of reserving a register for a fixed value.

The register value would also signal the other elements of this
platform spec are being followed. Notably including that a1

actually

points to a valid device tree. If we could count on a device tree
always being present then I agree that going the /chosen route

would

be cleaner, but if a future third party standard decided to go

with

ACPI tables or something instead then they may not be willing to
require a dummy device tree just to allow software to blindly
dereference a1.

For ACPI tables, a similar property can be added in the ACPI table.
We anyways have to add other run time properties to ACPI table as
we do
currently for the device tree.

Jonathan

To give one case where this already seems to be coming up,

Linux

can run in M-mode instead of S-mode but only if it is

configured

that way at compile time. If Linux had a better way to know
whether there was firmware present, it might be able to use a
shared kernel binary for both cases.

Best,
Jonathan

On Wed, Jun 17, 2020 at 2:56 PM Atish Patra <

Atish.Patra@...>

wrote:

On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens wrote:

Hi everyone,

To start off discussion about requirements that should go

into the

platform spec, I propose a simple change to current

software:

When entering S-mode for the first time, the a2 register

should

contain the value 0x54414c5058494e55 ("UNIXPLAT").

The intention here is that software should be able to

look

for this

value and know that it has been booted in a Supervisor

Execution

Environment that is compliant with the Unix-class

platform

spec. This

would distinguish both from old implementations that only

support SBI

v0.1, but also possible future execution environments

designed by

other groups.

For SBI version, supervisor systems should use
"sbi_get_spec_version"
API to identify what is the SBI version of the SBI
implementation. For
v0.1, the above call will return a -ve value indicating

that

this is a
v0.1.

That's how linux kernel currently detects the SBI version
dynamically.

Jonathan

--
Regards,
Atish

On Fri, 2020-06-26 at 15:12 -0400, Jonathan Behrens wrote:

On Wed, Jun 24, 2020 at 1:55 PM Atish Patra <Atish.Patra@...>
wrote:

On Wed, 2020-06-24 at 13:04 -0400, Jonathan Behrens wrote:

But how will the booting OS know whether to look at ACPI tables

or

the device tree? Wouldn't you need some register to indicate

which

one is being used?

I am not sure how it will be implemented in RISC-V when we have
ACPI.
However, this is process followed in ARM64[1]

ACPI tables are passed via UEFI system configuration table while DT
address will be passed in x0. Kernel tries to use DT first if ACPI
is
not preferred choice from kernel commandline. If it fails to find a
DT,
it will try to use ACPI table if exists.


[1] https://lwn.net/Articles/642050/

From that link it looks like the OS already has access to the kernel
command line and the EFI system table before it starts looking at the
DT / ACPI tables?

Yes. ACPI is only usable via UEFI boot. Thus, EFI system table is
already available with kernel. Even though kernel looks at DT, before
looking at EFI system table, it removes all the memory mappings from DT
for efi boot and reinitilizes all memory blocks from efi memory
mappings.

In that case, the bootloader has already passed enough relevant
information for the OS to know that it isn't about to dereference a
bad pointer or something when trying to read from the DT.

However, perhaps I've been too pessimistic about the RISC-V ecosystem
all conforming to the Unix-class platform spec. I'm way more familiar
with x86 which didn't really manage to achieve something like this,
but it looks like maybe ARM did?

I guess ARM has to do it because it had to support both DT & ACPI
unlike x86. We may have to follow similar approach for RISC-V as well
in future.

If changes like adding ACPI tables or whatever are all done in a
compatible way (say by having a stub DT) there there is no need for a
magic number. If there are going to be multiple conflicting
standards, then proactively using one out of the 31 registers to tell
the apart might be worthwhile.

I am hoping there will not be any conflicting standards and we add
everything in a compatiable way. For Linux land, we try to keep single
Linux kernel image booting all platforms (supporting S-mode).

Jonathan

PS: I started this thread focusing on a small/not too technical
question partially in the hope of generating more discussion on this
mailing list. Please chime in if you have thoughts!

On Wed, Jun 24, 2020 at 11:18 AM Atish Patra via lists.riscv.org

<

atish.patra=wdc.com@...> wrote:

On Tue, 2020-06-23 at 16:37 -0400, Jonathan Behrens wrote:

On Fri, Jun 19, 2020 at 5:42 PM Atish Patra <

Atish.Patra@...>

wrote:

On Jun 19, 2020, at 1:26 PM, Jonathan Behrens <

behrensj@...>

wrote:

Thanks for that clarification! It is good to know that

SBI

v0.1

implementations are consistent about returning negative

values

for functions they don't recognize like

sbi_get_spec_version.

This however doesn't work for environments which cannot

or

don't

want to implement the SBI at all (what value do you

return to

say

there is no SBI?)

Once RISC-V is more widely deployed, it is likely that

there

will

be more platform specs written by other committees, or

even

groups entirely outside of the RISC-V foundation. They

may

not

want to require ecalls to detect capabilities, or might

have

other constraints. Yet, developers will likely want to

write

kernels that can boot across a range of these different
environments. This has certainly been the case on x86

where

there's lots of different bootloaders that each work with

their

own conventions.

Yes. That’s a possibility. If I understand you correctly,

you

want

some identifier that let supervisor know that the M-mode
firmware is an SBI based one.

If that’s the only case, how about a DT property under

/chosen

node

instead of reserving a register for a fixed value.

The register value would also signal the other elements of

this

platform spec are being followed. Notably including that a1

actually

points to a valid device tree. If we could count on a device

tree

always being present then I agree that going the /chosen

route

would

be cleaner, but if a future third party standard decided to

go

with

ACPI tables or something instead then they may not be willing

to

require a dummy device tree just to allow software to blindly
dereference a1.

For ACPI tables, a similar property can be added in the ACPI

table.

We anyways have to add other run time properties to ACPI table

as

we do
currently for the device tree.

Jonathan

To give one case where this already seems to be coming

up,

Linux

can run in M-mode instead of S-mode but only if it is

configured

that way at compile time. If Linux had a better way to

know

whether there was firmware present, it might be able to

use a

shared kernel binary for both cases.

Best,
Jonathan

On Wed, Jun 17, 2020 at 2:56 PM Atish Patra <

Atish.Patra@...>

wrote:

On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens

wrote:

Hi everyone,

To start off discussion about requirements that

should go

into the

platform spec, I propose a simple change to current

software:

When entering S-mode for the first time, the a2

register

should

contain the value 0x54414c5058494e55 ("UNIXPLAT").

The intention here is that software should be able to

look

for this

value and know that it has been booted in a

Supervisor

Execution

Environment that is compliant with the Unix-class

platform

spec. This

would distinguish both from old implementations that

only

support SBI

v0.1, but also possible future execution environments

designed by

other groups.

For SBI version, supervisor systems should use
"sbi_get_spec_version"
API to identify what is the SBI version of the SBI
implementation. For
v0.1, the above call will return a -ve value indicating

that

this is a
v0.1.

That's how linux kernel currently detects the SBI

version

dynamically.

Jonathan

--
Regards,
Atish

My apologies for digging around in old threads ... I've had an interest
in archaeology since I was quite young :) ....

On 26 Jun 2020 19:29, Atish Patra wrote:

On Fri, 2020-06-26 at 15:12 -0400, Jonathan Behrens wrote:

On Wed, Jun 24, 2020 at 1:55 PM Atish Patra <Atish.Patra@...>
wrote:

On Wed, 2020-06-24 at 13:04 -0400, Jonathan Behrens wrote:

But how will the booting OS know whether to look at ACPI tables

or

the device tree? Wouldn't you need some register to indicate

which

one is being used?

I am not sure how it will be implemented in RISC-V when we have
ACPI.
However, this is process followed in ARM64[1]

ACPI tables are passed via UEFI system configuration table while DT
address will be passed in x0. Kernel tries to use DT first if ACPI
is
not preferred choice from kernel commandline. If it fails to find a
DT,
it will try to use ACPI table if exists.


[1] https://lwn.net/Articles/642050/

I'd forgotten I'd written that :). Yeesh. I was going to argue with
the author -- and I should probably update it.

From that link it looks like the OS already has access to the kernel
command line and the EFI system table before it starts looking at the
DT / ACPI tables?

Yes. ACPI is only usable via UEFI boot. Thus, EFI system table is
already available with kernel. Even though kernel looks at DT, before
looking at EFI system table, it removes all the memory mappings from DT
for efi boot and reinitilizes all memory blocks from efi memory
mappings.

Somewhat simplified. ACPI can be used without UEFI -- that's how I
did the initial port on arm64. It's not typically used, though; it
is the SBSA/SBBR that require UEFI and ACPI on arm64 servers. The
only real connection between the two is that the EFI system table
provides the address to the beginning of the ACPI data structures.

When booting with UEFI, the memory map is provided by UEFI; the only
thing in the DT is a /chosen node with the kernel arguments that
need to be passed in. An initial 1:1 map is setup, then the UEFI
memory map is read and eventually VM is turned on. Once it has,
then ACPI can start enumerating devices.

The kernel checks this initial DT to see if there is more in it than
the /chosen node. If there is, then it assumes DT is where all of
the device enumeration info is.

In that case, the bootloader has already passed enough relevant
information for the OS to know that it isn't about to dereference a
bad pointer or something when trying to read from the DT.

However, perhaps I've been too pessimistic about the RISC-V ecosystem
all conforming to the Unix-class platform spec. I'm way more familiar
with x86 which didn't really manage to achieve something like this,
but it looks like maybe ARM did?

I guess ARM has to do it because it had to support both DT & ACPI
unlike x86. We may have to follow similar approach for RISC-V as well
in future.

If changes like adding ACPI tables or whatever are all done in a
compatible way (say by having a stub DT) there there is no need for a
magic number. If there are going to be multiple conflicting
standards, then proactively using one out of the 31 registers to tell
the apart might be worthwhile.

I am hoping there will not be any conflicting standards and we add
everything in a compatiable way. For Linux land, we try to keep single
Linux kernel image booting all platforms (supporting S-mode).

I think the platform spec committee all agrees -- conflicting standards
are A Really Bad Idea. And this is *definitely* on the TODO list
so we can avoid multiple kernel images.

Jonathan

PS: I started this thread focusing on a small/not too technical
question partially in the hope of generating more discussion on this
mailing list. Please chime in if you have thoughts!

On Wed, Jun 24, 2020 at 11:18 AM Atish Patra via lists.riscv.org

<

atish.patra=wdc.com@...> wrote:

On Tue, 2020-06-23 at 16:37 -0400, Jonathan Behrens wrote:

On Fri, Jun 19, 2020 at 5:42 PM Atish Patra <

Atish.Patra@...>

wrote:

On Jun 19, 2020, at 1:26 PM, Jonathan Behrens <

behrensj@...>

wrote:

Thanks for that clarification! It is good to know that

SBI

v0.1

implementations are consistent about returning negative

values

for functions they don't recognize like

sbi_get_spec_version.

This however doesn't work for environments which cannot

or

don't

want to implement the SBI at all (what value do you

return to

say

there is no SBI?)

Once RISC-V is more widely deployed, it is likely that

there

will

be more platform specs written by other committees, or

even

groups entirely outside of the RISC-V foundation. They

may

not

want to require ecalls to detect capabilities, or might

have

other constraints. Yet, developers will likely want to

write

kernels that can boot across a range of these different
environments. This has certainly been the case on x86

where

there's lots of different bootloaders that each work with

their

own conventions.

Yes. That’s a possibility. If I understand you correctly,

you

want

some identifier that let supervisor know that the M-mode
firmware is an SBI based one.

If that’s the only case, how about a DT property under

/chosen

node

instead of reserving a register for a fixed value.

The register value would also signal the other elements of

this

platform spec are being followed. Notably including that a1

actually

points to a valid device tree. If we could count on a device

tree

always being present then I agree that going the /chosen

route

would

be cleaner, but if a future third party standard decided to

go

with

ACPI tables or something instead then they may not be willing

to

require a dummy device tree just to allow software to blindly
dereference a1.

For ACPI tables, a similar property can be added in the ACPI

table.

We anyways have to add other run time properties to ACPI table

as

we do
currently for the device tree.

Jonathan

To give one case where this already seems to be coming

up,

Linux

can run in M-mode instead of S-mode but only if it is

configured

that way at compile time. If Linux had a better way to

know

whether there was firmware present, it might be able to

use a

shared kernel binary for both cases.

Best,
Jonathan

On Wed, Jun 17, 2020 at 2:56 PM Atish Patra <

Atish.Patra@...>

wrote:

On Tue, 2020-06-16 at 09:54 -0400, Jonathan Behrens

wrote:

Hi everyone,

To start off discussion about requirements that

should go

into the

platform spec, I propose a simple change to current

software:

When entering S-mode for the first time, the a2

register

should

contain the value 0x54414c5058494e55 ("UNIXPLAT").

The intention here is that software should be able to

look

for this

value and know that it has been booted in a

Supervisor

Execution

Environment that is compliant with the Unix-class

platform

spec. This

would distinguish both from old implementations that

only

support SBI

v0.1, but also possible future execution environments

designed by

other groups.

For SBI version, supervisor systems should use
"sbi_get_spec_version"
API to identify what is the SBI version of the SBI
implementation. For
v0.1, the above call will return a -ve value indicating

that

this is a
v0.1.

That's how linux kernel currently detects the SBI

version

dynamically.

Jonathan

--
Regards,
Atish

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@...
-----------------------------------