Date   

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

Abner Chang <abner.chang@...>
 

and that is fine if other firmware code base use the same 0xA000000 + opensbi_imp_id however the extension is incompatible each other, because the firmware code base SBI is very firmware code base implementation specific.

 

The only possible risk if someone would like to provide a common firmware driver for all firmware code base, it has no way to tell which firmware code base is with OpenSBI. With this case, that common firmware driver doesn’t know what the extension it has to use. I had considered this situation but I think this is a rare case (and maybe no use case) though.

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Tuesday, April 14, 2020 11:35 AM
To: Jonathan Behrens <behrensj@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Jonathan,

 

With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode perspective the underlying SBI implementation is still OpenSBI. The OpenSBI itself does not need the SBI firmware code base extension hence I suggested that EDK2 can use ext_id = 0xA000000 + opensbi_imp_id.

 

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code extension won’t be available because OpenSBI firmwares will not implement it.

 

Apart from bootloaders, the SBI firmware code base extension space can be used hypervisors to provide hypervisor specific SBI calls.

 

Regards,

Anup

 

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID?

 

Jonathan

 

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

Yes, your understanding is correct.

 

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI.

 

Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself.

 

From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback).

 

Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

 

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now.

 

That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension.

[Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI  spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation.

 

Anup, is my understanding correct?

Abner

 

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote:

Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment.

Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension.

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones.

We can just take #1 opinion.

 

Any other comments?

 

Will let you know if we miss something later. Thanks to all for supporting ekd2.

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension.

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

We have two options here:

  1. EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
  2. OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API)

 

If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2.

 

Let us know what you guys think in this context.

 

Regards,

Anup

 

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change.

https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4

 

  • EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension.

We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation.

  • What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI.

We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation.

 

Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense?

  • Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc..
  • Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID.
  • Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension
  • Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits.

 

I feel the later one makes more sense and clear, how do you think?

Abner

 

 

From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Cool. This works for edk2. I will have another PR for this.

 

For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase.

 

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot extension.

Regards,

Anup

Sent from Outlook Mobile

 


From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

What I was suggesting is something like:

 

> Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. 

 

In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting.

 

As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it.

 

Jonathan

 

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:



> -----Original Message-----
> From: tech-unixplatformspec@... [mailto:tech-
> unixplatformspec@...] On Behalf Of Atish Patra
> Sent: Friday, April 10, 2020 11:32 AM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
> behrensj@...
> Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-
> unixplatformspec@...; Anup Patel <Anup.Patel@...>
> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI
> extension space for firmware code base implementation
>
> On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > Got it, Software ML removed.
> >
> > Johnathan, do you mean to define it as below?
> > Firmware Base Extension, Extension ID: 0xxxxxxxxx  (FWBE) , and the
> > SBI functions definition is firmware code base implementation-
> > specific.
> >
>
> I prefer this one as well. But you should pick any value within experimental
> range.
Not quite follow this, why pick up one from experimental range?  The extension ID must be in the range of 0x0800000-0x08ffffff?

I am not sure about the purpose of the extension but if it has the
> potential to be a generic SBI extension for firmwares, you should propose it
> to the Unix Platform working group. We can add it to the official spec.
For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension.
Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts.

>
> > This also works for me and better than to reserve a range of IDs.
> > Thanks
> > Abner
> >
> > From: software@... [mailto:software@...] On
> > Behalf Of Jonathan Behrens
> > Sent: Friday, April 10, 2020 12:39 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
> > Cc: Atish Patra <Atish.Patra@...>; Anup Patel
> <anup.patel@...
> > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>;
> > software@...; tech-unixplatformspec@...
> > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware
> > code base implementation
> >
> > I think tech-unixplatformspec@... might be the right list?
> >
> > To address the PR itself, I'd personally prefer to have this space
> > allocated based on SBI implementation IDs analogously to how the
> > vendor space is allocated. It also probably makes sense to pick a
> > different address range so experimental extension space doesn't have
> > to move.
> >
> > Jonathan
> >
> > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <
> > abner.chang=hpe.com@...> wrote:
> > > Seems opensbi ML is no longer exist? Use software@...
> > > insrtead.
> > >
> > > From: Chang, Abner (HPS SW/FW Technologist)
> > > Sent: Thursday, April 9, 2020 4:23 PM
> > > To: Atish Patra <Atish.Patra@...>; Anup Patel <
> > > anup.patel@...>
> > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) <
> > > daniel.schaefer@...>
> > > Subject: Add SBI extension space for firmware code base
> > > implementation
> > >
> > > Hi Atish and Anup,
> > > We are working on some edk2-specific SBI extension which intends to
> > > be used by upper layer edk2 drivers. We originally consider to use
> > > Vendor Extension space however vendor may have its own proprietary
> > > SBI extension as well. In order to prevent from the conflicts of SBI
> > > extension space, we propose to have a range for firmware code base.
> > > The changes look like the PR below,
> > >
> > > https://github.com/riscv/riscv-sbi-doc/pull/43
> > >
> > > How do you think?
> > > Thanks
> > > Abner
> >
> >
>
> --
> Regards,
> Atish
>
>


Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

Jonathan Behrens <behrensj@...>
 

Anup wrote:

With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode perspective the underlying SBI implementation is still OpenSBI.


But EDK2 can and will register extensions with OpenSBI, meaning that even identical OpenSBI versions might behave differently with regards to such extension. So far I think you are right that S-mode won't actually care about the difference. But I fear that this could end up like User Agent Strings in web browsers where everybody lies and claims they're basically the same as OpenSBI so they report the same implementation ID.
 

The OpenSBI itself does not need the SBI firmware code base extension hence I suggested that EDK2 can use ext_id = 0xA000000 + opensbi_imp_id.

 

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code extension won’t be available because OpenSBI firmwares will not implement it.


Are you saying that you are or aren't OK with U-Boot or Coreboot hypothetically using ext_id = 0xA000000 + opensbi_imp_id to design their own incompatible extensions? As Abner points out below, it would probably be fine even if there were incompatible extensions with the same ID, but I'm trying to understand if that's what you intend. (My own opinion is that with 2^32 possible IDs it would be preferable to try to keep them distinct)

Apart from bootloaders, the SBI firmware code base extension space can be used hypervisors to provide hypervisor specific SBI calls.


Agreed. I think this reservation will prove to be very useful going forward.

Jonathan


Regards,

Anup

 

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID?

 

Jonathan

 

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

Yes, your understanding is correct.

 

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI.

 

Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself.

 

From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback).

 

Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

 

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now.

 

That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension.

[Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI  spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation.

 

Anup, is my understanding correct?

Abner

 

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote:

Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment.

Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension.

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones.

We can just take #1 opinion.

 

Any other comments?

 

Will let you know if we miss something later. Thanks to all for supporting ekd2.

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension.

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

We have two options here:

  1. EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
  2. OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API)

 

If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2.

 

Let us know what you guys think in this context.

 

Regards,

Anup

 

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change.

https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4

 

  • EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension.

We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation.

  • What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI.

We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation.

 

Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense?

  • Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc..
  • Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID.
  • Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension
  • Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits.

 

I feel the later one makes more sense and clear, how do you think?

Abner

 

 

From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Cool. This works for edk2. I will have another PR for this.

 

For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase.

 

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot extension.

Regards,

Anup

Sent from Outlook Mobile

 


From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

What I was suggesting is something like:

 

> Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. 

 

In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting.

 

As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it.

 

Jonathan

 

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:



> -----Original Message-----
> From: tech-unixplatformspec@... [mailto:tech-
> unixplatformspec@...] On Behalf Of Atish Patra
> Sent: Friday, April 10, 2020 11:32 AM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
> behrensj@...
> Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-
> unixplatformspec@...; Anup Patel <Anup.Patel@...>
> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI
> extension space for firmware code base implementation
>
> On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > Got it, Software ML removed.
> >
> > Johnathan, do you mean to define it as below?
> > Firmware Base Extension, Extension ID: 0xxxxxxxxx  (FWBE) , and the
> > SBI functions definition is firmware code base implementation-
> > specific.
> >
>
> I prefer this one as well. But you should pick any value within experimental
> range.
Not quite follow this, why pick up one from experimental range?  The extension ID must be in the range of 0x0800000-0x08ffffff?

I am not sure about the purpose of the extension but if it has the
> potential to be a generic SBI extension for firmwares, you should propose it
> to the Unix Platform working group. We can add it to the official spec.
For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension.
Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts.

>
> > This also works for me and better than to reserve a range of IDs.
> > Thanks
> > Abner
> >
> > From: software@... [mailto:software@...] On
> > Behalf Of Jonathan Behrens
> > Sent: Friday, April 10, 2020 12:39 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
> > Cc: Atish Patra <Atish.Patra@...>; Anup Patel
> <anup.patel@...
> > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>;
> > software@...; tech-unixplatformspec@...
> > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware
> > code base implementation
> >
> > I think tech-unixplatformspec@... might be the right list?
> >
> > To address the PR itself, I'd personally prefer to have this space
> > allocated based on SBI implementation IDs analogously to how the
> > vendor space is allocated. It also probably makes sense to pick a
> > different address range so experimental extension space doesn't have
> > to move.
> >
> > Jonathan
> >
> > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <
> > abner.chang=hpe.com@...> wrote:
> > > Seems opensbi ML is no longer exist? Use software@...
> > > insrtead.
> > >
> > > From: Chang, Abner (HPS SW/FW Technologist)
> > > Sent: Thursday, April 9, 2020 4:23 PM
> > > To: Atish Patra <Atish.Patra@...>; Anup Patel <
> > > anup.patel@...>
> > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) <
> > > daniel.schaefer@...>
> > > Subject: Add SBI extension space for firmware code base
> > > implementation
> > >
> > > Hi Atish and Anup,
> > > We are working on some edk2-specific SBI extension which intends to
> > > be used by upper layer edk2 drivers. We originally consider to use
> > > Vendor Extension space however vendor may have its own proprietary
> > > SBI extension as well. In order to prevent from the conflicts of SBI
> > > extension space, we propose to have a range for firmware code base.
> > > The changes look like the PR below,
> > >
> > > https://github.com/riscv/riscv-sbi-doc/pull/43
> > >
> > > How do you think?
> > > Thanks
> > > Abner
> >
> >
>
> --
> Regards,
> Atish
>
>


Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

Anup Patel
 

As-per my understanding, U-Boot and Coreboot don’t need this SBI firmware code base extension. Other SBI extensions are sufficient for these bootloaders.

 

In my opinion, use of SBI firmware code base extension should be last resort (when we have no other way) because this extension adds SBI implementation specific code in S-mode software. The EDK2 developers want to use SBI firmware code base extension in their own S-mode booting stage so we are fine in-context of EDK2.

 

Also, we are certainly fine if EDK2 want their own SBI implementation ID and to facilitate OpenSBI can provide API to override SBI implementation ID which EDK2 can use. Finally, it’s EDK2 developer’s choice.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Jonathan Behrens
Sent: 14 April 2020 09:50
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup wrote:

With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode perspective the underlying SBI implementation is still OpenSBI.

 

But EDK2 can and will register extensions with OpenSBI, meaning that even identical OpenSBI versions might behave differently with regards to such extension. So far I think you are right that S-mode won't actually care about the difference. But I fear that this could end up like User Agent Strings in web browsers where everybody lies and claims they're basically the same as OpenSBI so they report the same implementation ID.

 

The OpenSBI itself does not need the SBI firmware code base extension hence I suggested that EDK2 can use ext_id = 0xA000000 + opensbi_imp_id.

 

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code extension won’t be available because OpenSBI firmwares will not implement it.

 

Are you saying that you are or aren't OK with U-Boot or Coreboot hypothetically using ext_id = 0xA000000 + opensbi_imp_id to design their own incompatible extensions? As Abner points out below, it would probably be fine even if there were incompatible extensions with the same ID, but I'm trying to understand if that's what you intend. (My own opinion is that with 2^32 possible IDs it would be preferable to try to keep them distinct)

 

Apart from bootloaders, the SBI firmware code base extension space can be used hypervisors to provide hypervisor specific SBI calls.

 

Agreed. I think this reservation will prove to be very useful going forward.

 

Jonathan

 

Regards,

Anup

 

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID?

 

Jonathan

 

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

Yes, your understanding is correct.

 

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI.

 

Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself.

 

From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback).

 

Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

 

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now.

 

That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension.

[Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI  spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation.

 

Anup, is my understanding correct?

Abner

 

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote:

Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment.

Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension.

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones.

We can just take #1 opinion.

 

Any other comments?

 

Will let you know if we miss something later. Thanks to all for supporting ekd2.

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension.

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

We have two options here:

  1. EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
  2. OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API)

 

If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2.

 

Let us know what you guys think in this context.

 

Regards,

Anup

 

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change.

https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4

 

  • EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension.

We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation.

  • What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI.

We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation.

 

Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense?

  • Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc..
  • Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID.
  • Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension
  • Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits.

 

I feel the later one makes more sense and clear, how do you think?

Abner

 

 

From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Cool. This works for edk2. I will have another PR for this.

 

For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase.

 

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot extension.

Regards,

Anup

Sent from Outlook Mobile

 


From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

What I was suggesting is something like:

 

> Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. 

 

In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting.

 

As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it.

 

Jonathan

 

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:



> -----Original Message-----
> From: tech-unixplatformspec@... [mailto:tech-
> unixplatformspec@...] On Behalf Of Atish Patra
> Sent: Friday, April 10, 2020 11:32 AM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
> behrensj@...
> Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-
> unixplatformspec@...; Anup Patel <Anup.Patel@...>
> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI
> extension space for firmware code base implementation
>
> On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > Got it, Software ML removed.
> >
> > Johnathan, do you mean to define it as below?
> > Firmware Base Extension, Extension ID: 0xxxxxxxxx  (FWBE) , and the
> > SBI functions definition is firmware code base implementation-
> > specific.
> >
>
> I prefer this one as well. But you should pick any value within experimental
> range.
Not quite follow this, why pick up one from experimental range?  The extension ID must be in the range of 0x0800000-0x08ffffff?

I am not sure about the purpose of the extension but if it has the
> potential to be a generic SBI extension for firmwares, you should propose it
> to the Unix Platform working group. We can add it to the official spec.
For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension.
Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts.

>
> > This also works for me and better than to reserve a range of IDs.
> > Thanks
> > Abner
> >
> > From: software@... [mailto:software@...] On
> > Behalf Of Jonathan Behrens
> > Sent: Friday, April 10, 2020 12:39 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
> > Cc: Atish Patra <Atish.Patra@...>; Anup Patel
> <anup.patel@...
> > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>;
> > software@...; tech-unixplatformspec@...
> > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware
> > code base implementation
> >
> > I think tech-unixplatformspec@... might be the right list?
> >
> > To address the PR itself, I'd personally prefer to have this space
> > allocated based on SBI implementation IDs analogously to how the
> > vendor space is allocated. It also probably makes sense to pick a
> > different address range so experimental extension space doesn't have
> > to move.
> >
> > Jonathan
> >
> > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <
> > abner.chang=hpe.com@...> wrote:
> > > Seems opensbi ML is no longer exist? Use software@...
> > > insrtead.
> > >
> > > From: Chang, Abner (HPS SW/FW Technologist)
> > > Sent: Thursday, April 9, 2020 4:23 PM
> > > To: Atish Patra <Atish.Patra@...>; Anup Patel <
> > > anup.patel@...>
> > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) <
> > > daniel.schaefer@...>
> > > Subject: Add SBI extension space for firmware code base
> > > implementation
> > >
> > > Hi Atish and Anup,
> > > We are working on some edk2-specific SBI extension which intends to
> > > be used by upper layer edk2 drivers. We originally consider to use
> > > Vendor Extension space however vendor may have its own proprietary
> > > SBI extension as well. In order to prevent from the conflicts of SBI
> > > extension space, we propose to have a range for firmware code base.
> > > The changes look like the PR below,
> > >
> > > https://github.com/riscv/riscv-sbi-doc/pull/43
> > >
> > > How do you think?
> > > Thanks
> > > Abner
> >
> >
>
> --
> Regards,
> Atish
>
>


Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

Abner Chang <abner.chang@...>
 

We would like to have firmware code base SBI  based on OpenSBI implementation ID, because edk2 is not one of the implementations of SBI. I saw the patches of overriding SBI implementation ID was also committed. EDK2 still has chance to override the ID to avoid any conflicts if it is a case.

 

BTW, the changes made on riscv-sbi-doc should go through the mail list for review or PR is good?

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Tuesday, April 14, 2020 1:25 PM
To: Jonathan Behrens <behrensj@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

As-per my understanding, U-Boot and Coreboot don’t need this SBI firmware code base extension. Other SBI extensions are sufficient for these bootloaders.

 

In my opinion, use of SBI firmware code base extension should be last resort (when we have no other way) because this extension adds SBI implementation specific code in S-mode software. The EDK2 developers want to use SBI firmware code base extension in their own S-mode booting stage so we are fine in-context of EDK2.

 

Also, we are certainly fine if EDK2 want their own SBI implementation ID and to facilitate OpenSBI can provide API to override SBI implementation ID which EDK2 can use. Finally, it’s EDK2 developer’s choice.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Jonathan Behrens
Sent: 14 April 2020 09:50
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup wrote:

With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode perspective the underlying SBI implementation is still OpenSBI.

 

But EDK2 can and will register extensions with OpenSBI, meaning that even identical OpenSBI versions might behave differently with regards to such extension. So far I think you are right that S-mode won't actually care about the difference. But I fear that this could end up like User Agent Strings in web browsers where everybody lies and claims they're basically the same as OpenSBI so they report the same implementation ID.

 

The OpenSBI itself does not need the SBI firmware code base extension hence I suggested that EDK2 can use ext_id = 0xA000000 + opensbi_imp_id.

 

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code extension won’t be available because OpenSBI firmwares will not implement it.

 

Are you saying that you are or aren't OK with U-Boot or Coreboot hypothetically using ext_id = 0xA000000 + opensbi_imp_id to design their own incompatible extensions? As Abner points out below, it would probably be fine even if there were incompatible extensions with the same ID, but I'm trying to understand if that's what you intend. (My own opinion is that with 2^32 possible IDs it would be preferable to try to keep them distinct)

 

Apart from bootloaders, the SBI firmware code base extension space can be used hypervisors to provide hypervisor specific SBI calls.

 

Agreed. I think this reservation will prove to be very useful going forward.

 

Jonathan

 

Regards,

Anup

 

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID?

 

Jonathan

 

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

Yes, your understanding is correct.

 

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI.

 

Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself.

 

From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback).

 

Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

 

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now.

 

That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension.

[Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI  spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation.

 

Anup, is my understanding correct?

Abner

 

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote:

Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment.

Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension.

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones.

We can just take #1 opinion.

 

Any other comments?

 

Will let you know if we miss something later. Thanks to all for supporting ekd2.

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension.

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

We have two options here:

  1. EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
  2. OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API)

 

If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2.

 

Let us know what you guys think in this context.

 

Regards,

Anup

 

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change.

https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4

 

  • EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension.

We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation.

  • What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI.

We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation.

 

Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense?

  • Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc..
  • Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID.
  • Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension
  • Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits.

 

I feel the later one makes more sense and clear, how do you think?

Abner

 

 

From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Cool. This works for edk2. I will have another PR for this.

 

For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase.

 

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot extension.

Regards,

Anup

Sent from Outlook Mobile

 


From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

What I was suggesting is something like:

 

> Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. 

 

In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting.

 

As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it.

 

Jonathan

 

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:



> -----Original Message-----
> From: tech-unixplatformspec@... [mailto:tech-
> unixplatformspec@...] On Behalf Of Atish Patra
> Sent: Friday, April 10, 2020 11:32 AM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
> behrensj@...
> Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-
> unixplatformspec@...; Anup Patel <Anup.Patel@...>
> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI
> extension space for firmware code base implementation
>
> On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > Got it, Software ML removed.
> >
> > Johnathan, do you mean to define it as below?
> > Firmware Base Extension, Extension ID: 0xxxxxxxxx  (FWBE) , and the
> > SBI functions definition is firmware code base implementation-
> > specific.
> >
>
> I prefer this one as well. But you should pick any value within experimental
> range.
Not quite follow this, why pick up one from experimental range?  The extension ID must be in the range of 0x0800000-0x08ffffff?

I am not sure about the purpose of the extension but if it has the
> potential to be a generic SBI extension for firmwares, you should propose it
> to the Unix Platform working group. We can add it to the official spec.
For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension.
Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts.

>
> > This also works for me and better than to reserve a range of IDs.
> > Thanks
> > Abner
> >
> > From: software@... [mailto:software@...] On
> > Behalf Of Jonathan Behrens
> > Sent: Friday, April 10, 2020 12:39 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
> > Cc: Atish Patra <Atish.Patra@...>; Anup Patel
> <anup.patel@...
> > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>;
> > software@...; tech-unixplatformspec@...
> > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware
> > code base implementation
> >
> > I think tech-unixplatformspec@... might be the right list?
> >
> > To address the PR itself, I'd personally prefer to have this space
> > allocated based on SBI implementation IDs analogously to how the
> > vendor space is allocated. It also probably makes sense to pick a
> > different address range so experimental extension space doesn't have
> > to move.
> >
> > Jonathan
> >
> > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <
> > abner.chang=hpe.com@...> wrote:
> > > Seems opensbi ML is no longer exist? Use software@...
> > > insrtead.
> > >
> > > From: Chang, Abner (HPS SW/FW Technologist)
> > > Sent: Thursday, April 9, 2020 4:23 PM
> > > To: Atish Patra <Atish.Patra@...>; Anup Patel <
> > > anup.patel@...>
> > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) <
> > > daniel.schaefer@...>
> > > Subject: Add SBI extension space for firmware code base
> > > implementation
> > >
> > > Hi Atish and Anup,
> > > We are working on some edk2-specific SBI extension which intends to
> > > be used by upper layer edk2 drivers. We originally consider to use
> > > Vendor Extension space however vendor may have its own proprietary
> > > SBI extension as well. In order to prevent from the conflicts of SBI
> > > extension space, we propose to have a range for firmware code base.
> > > The changes look like the PR below,
> > >
> > > https://github.com/riscv/riscv-sbi-doc/pull/43
> > >
> > > How do you think?
> > > Thanks
> > > Abner
> >
> >
>
> --
> Regards,
> Atish
>
>


Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

Anup Patel
 

For riscv-sbi-doc, we have not finalized mailing list based review OR Github PR based review so most of usl are sending riscv-sbi-doc changes as patches to mailing list and Github PR.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 21 April 2020 08:26
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

We would like to have firmware code base SBI  based on OpenSBI implementation ID, because edk2 is not one of the implementations of SBI. I saw the patches of overriding SBI implementation ID was also committed. EDK2 still has chance to override the ID to avoid any conflicts if it is a case.

 

BTW, the changes made on riscv-sbi-doc should go through the mail list for review or PR is good?

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Tuesday, April 14, 2020 1:25 PM
To: Jonathan Behrens <behrensj@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

As-per my understanding, U-Boot and Coreboot don’t need this SBI firmware code base extension. Other SBI extensions are sufficient for these bootloaders.

 

In my opinion, use of SBI firmware code base extension should be last resort (when we have no other way) because this extension adds SBI implementation specific code in S-mode software. The EDK2 developers want to use SBI firmware code base extension in their own S-mode booting stage so we are fine in-context of EDK2.

 

Also, we are certainly fine if EDK2 want their own SBI implementation ID and to facilitate OpenSBI can provide API to override SBI implementation ID which EDK2 can use. Finally, it’s EDK2 developer’s choice.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Jonathan Behrens
Sent: 14 April 2020 09:50
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup wrote:

With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode perspective the underlying SBI implementation is still OpenSBI.

 

But EDK2 can and will register extensions with OpenSBI, meaning that even identical OpenSBI versions might behave differently with regards to such extension. So far I think you are right that S-mode won't actually care about the difference. But I fear that this could end up like User Agent Strings in web browsers where everybody lies and claims they're basically the same as OpenSBI so they report the same implementation ID.

 

The OpenSBI itself does not need the SBI firmware code base extension hence I suggested that EDK2 can use ext_id = 0xA000000 + opensbi_imp_id.

 

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code extension won’t be available because OpenSBI firmwares will not implement it.

 

Are you saying that you are or aren't OK with U-Boot or Coreboot hypothetically using ext_id = 0xA000000 + opensbi_imp_id to design their own incompatible extensions? As Abner points out below, it would probably be fine even if there were incompatible extensions with the same ID, but I'm trying to understand if that's what you intend. (My own opinion is that with 2^32 possible IDs it would be preferable to try to keep them distinct)

 

Apart from bootloaders, the SBI firmware code base extension space can be used hypervisors to provide hypervisor specific SBI calls.

 

Agreed. I think this reservation will prove to be very useful going forward.

 

Jonathan

 

Regards,

Anup

 

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID?

 

Jonathan

 

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

Yes, your understanding is correct.

 

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI.

 

Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself.

 

From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback).

 

Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context.

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

 

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now.

 

That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension.

[Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI  spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation.

 

Anup, is my understanding correct?

Abner

 

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote:

Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment.

Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension.

 

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones.

We can just take #1 opinion.

 

Any other comments?

 

Will let you know if we miss something later. Thanks to all for supporting ekd2.

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension.

 

Jonathan

 

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote:

Hi Abner,

 

We have two options here:

  1. EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
  2. OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API)

 

If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2.

 

Let us know what you guys think in this context.

 

Regards,

Anup

 

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change.

https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4

 

  • EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension.

We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation.

  • What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI.

We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation.

 

Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense?

  • Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc..
  • Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID.
  • Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension
  • Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits.

 

I feel the later one makes more sense and clear, how do you think?

Abner

 

 

From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

Cool. This works for edk2. I will have another PR for this.

 

For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase.

 

 

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot extension.

Regards,

Anup

Sent from Outlook Mobile

 


From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation

 

What I was suggesting is something like:

 

> Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. 

 

In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting.

 

As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it.

 

Jonathan

 

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:



> -----Original Message-----
> From: tech-unixplatformspec@... [mailto:tech-
> unixplatformspec@...] On Behalf Of Atish Patra
> Sent: Friday, April 10, 2020 11:32 AM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
> behrensj@...
> Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-
> unixplatformspec@...; Anup Patel <Anup.Patel@...>
> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI
> extension space for firmware code base implementation
>
> On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > Got it, Software ML removed.
> >
> > Johnathan, do you mean to define it as below?
> > Firmware Base Extension, Extension ID: 0xxxxxxxxx  (FWBE) , and the
> > SBI functions definition is firmware code base implementation-
> > specific.
> >
>
> I prefer this one as well. But you should pick any value within experimental
> range.
Not quite follow this, why pick up one from experimental range?  The extension ID must be in the range of 0x0800000-0x08ffffff?

I am not sure about the purpose of the extension but if it has the
> potential to be a generic SBI extension for firmwares, you should propose it
> to the Unix Platform working group. We can add it to the official spec.
For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension.
Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts.

>
> > This also works for me and better than to reserve a range of IDs.
> > Thanks
> > Abner
> >
> > From: software@... [mailto:software@...] On
> > Behalf Of Jonathan Behrens
> > Sent: Friday, April 10, 2020 12:39 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
> > Cc: Atish Patra <Atish.Patra@...>; Anup Patel
> <anup.patel@...
> > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>;
> > software@...; tech-unixplatformspec@...
> > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware
> > code base implementation
> >
> > I think tech-unixplatformspec@... might be the right list?
> >
> > To address the PR itself, I'd personally prefer to have this space
> > allocated based on SBI implementation IDs analogously to how the
> > vendor space is allocated. It also probably makes sense to pick a
> > different address range so experimental extension space doesn't have
> > to move.
> >
> > Jonathan
> >
> > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <
> > abner.chang=hpe.com@...> wrote:
> > > Seems opensbi ML is no longer exist? Use software@...
> > > insrtead.
> > >
> > > From: Chang, Abner (HPS SW/FW Technologist)
> > > Sent: Thursday, April 9, 2020 4:23 PM
> > > To: Atish Patra <Atish.Patra@...>; Anup Patel <
> > > anup.patel@...>
> > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) <
> > > daniel.schaefer@...>
> > > Subject: Add SBI extension space for firmware code base
> > > implementation
> > >
> > > Hi Atish and Anup,
> > > We are working on some edk2-specific SBI extension which intends to
> > > be used by upper layer edk2 drivers. We originally consider to use
> > > Vendor Extension space however vendor may have its own proprietary
> > > SBI extension as well. In order to prevent from the conflicts of SBI
> > > extension space, we propose to have a range for firmware code base.
> > > The changes look like the PR below,
> > >
> > > https://github.com/riscv/riscv-sbi-doc/pull/43
> > >
> > > How do you think?
> > > Thanks
> > > Abner
> >
> >
>
> --
> Regards,
> Atish
>
>


Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

atishp@...
 

On Tue, 2020-04-21 at 04:45 +0000, Anup Patel wrote:
For riscv-sbi-doc, we have not finalized mailing list based review OR
Github PR based review so most of usl are sending riscv-sbi-doc
changes as patches to mailing list and Github PR.

Regards,
Anup

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 21 April 2020 08:26
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <
behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add
SBI extension space for firmware code base implementation

We would like to have firmware code base SBI based on OpenSBI
implementation ID, because edk2 is not one of the implementations of
SBI. I saw the patches of overriding SBI implementation ID was also
committed. EDK2 still has chance to override the ID to avoid any
conflicts if it is a case.

BTW, the changes made on riscv-sbi-doc should go through the mail
list for review or PR is good?

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Tuesday, April 14, 2020 1:25 PM
To: Jonathan Behrens <behrensj@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add
SBI extension space for firmware code base implementation

As-per my understanding, U-Boot and Coreboot don’t need this SBI
firmware code base extension. Other SBI extensions are sufficient for
these bootloaders.

In my opinion, use of SBI firmware code base extension should be last
resort (when we have no other way) because this extension adds SBI
implementation specific code in S-mode software. The EDK2 developers
want to use SBI firmware code base extension in their own S-mode
booting stage so we are fine in-context of EDK2.

Also, we are certainly fine if EDK2 want their own SBI implementation
ID and to facilitate OpenSBI can provide API to override SBI
implementation ID which EDK2 can use. Finally, it’s EDK2 developer’s
choice.

Regards,
Anup

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> On Behalf Of Jonathan Behrens
Sent: 14 April 2020 09:50
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add
SBI extension space for firmware code base implementation

Anup wrote:
With EDK2 + OpenSBI running in background, the S-mode software will
see SBI implementation ID of OpenSBI because EDK2 uses unmodified
OpenSBI as library. This means from S-mode perspective the
underlying SBI implementation is still OpenSBI.

But EDK2 can and will register extensions with OpenSBI, meaning that
even identical OpenSBI versions might behave differently with regards
to such extension. So far I think you are right that S-mode won't
actually care about the difference. But I fear that this could end up
like User Agent Strings in web browsers where everybody lies and
claims they're basically the same as OpenSBI so they report the same
implementation ID.

The OpenSBI itself does not need the SBI firmware code base
extension hence I suggested that EDK2 can use ext_id = 0xA000000 +
opensbi_imp_id.

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI
FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code
extension won’t be available because OpenSBI firmwares will not
implement it.

Are you saying that you are or aren't OK with U-Boot or Coreboot
hypothetically using ext_id = 0xA000000 + opensbi_imp_id to design
their own incompatible extensions? As Abner points out below, it
would probably be fine even if there were incompatible extensions
with the same ID, but I'm trying to understand if that's what you
intend. (My own opinion is that with 2^32 possible IDs it would be
preferable to try to keep them distinct)

Apart from bootloaders, the SBI firmware code base extension space
can be used hypervisors to provide hypervisor specific SBI calls.

Agreed. I think this reservation will prove to be very useful going
forward.

Jonathan

Regards,
Anup

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software]
Add SBI extension space for firmware code base implementation

Anup, are you saying that EDK2's extension would be the only use of
ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses
OpenSBI is free to make a (potentially incompatible) extension
using that ID?

Jonathan

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...>
wrote:
Hi Abner,

Yes, your understanding is correct.

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base
extension meant to be used by OpenSBI.

Now EDK2 uses unmodified OpenSBI as library/submodule so
underlying SBI implementation in-case of EDK2 is indeed OpenSBI
itself.

From OpenSBI perspective, we don’t see any OpenSBI specific SBI
calls being implemented in-future because previous and next
booting stages are totally black-box for OpenSBI. This means SBI
Firmware code base extension will be never used by OpenSBI hence
EDK2 can certainly register custom SBI extension for ext_id =
0xA000000 + opensbi_imp_id (Note: EDK2 can use
sbi_ecall_register_extension() API for this from platform
final_init() callback).

Apart from above, I do see SBI firmware code base extension
useful to some of the hypervisors (such as Xvisor, Xen, etc) but
this is in totally different context.

Regards,
Anup

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software]
Add SBI extension space for firmware code base implementation



From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software]
Add SBI extension space for firmware code base implementation

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the
best and simple solution for now.

That is fine, just realize that if you are using OpenSBI's
implementation ID then you need to get approval from them before
defining the extension.
[Abner] I suppose the intention of reserving 0xa000000 is to let
firmware defines its own SBI functions. SBI spec won’t touch or
specify anything in this range as it doesn’t touch vendor
extension. To have 0xa000000 + opensbi_imp_id means the firmware
code base extension is defined base on OpenSBI SBI
implementation.

Anup, is my understanding correct?
Abner


Jonathan

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <
abner.chang=hpe.com@...> wrote:
Basically OpenSBI is a git submodule of edk2 and we don’t make
any modification on it, we just build OpenSBI on edk2 build
environment.
Yes, edk2 will have its own control of extensions for those
firmware code base specific functions. One think we concern
about is the conflict of extension ID with vendor extension.

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the
best and simple solution for now. We don’t have to add edk2 as
one of SBI implementation and this can also prevent from
extension ID conflict with vendor’s ones.
We can just take #1 opinion.

Any other comments?

Will let you know if we miss something later. Thanks to all for
supporting ekd2.
Abner

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
; Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

Is the code for the extension you want to add going to live in
the OpenSBI repository or in the EDK2 repository? If I
understand correctly, it would live in the EDK2 repository,
meaning that your implementation would actually be downstream
from OpenSBI and should have its own implementation ID. If you
did this then it seems like everything else would fall out
nicely: you could decide on version numbers independently of
OpenSBI, there'd be no need for a separate set of firmware IDs,
and you'd have full control over all the details of your
extension.

Jonathan

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...>
wrote:
Hi Abner,

We have two options here:
EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
OpenSBI provides a way to EDK2 for overriding SBI
implementation ID (preferably using some API)

If we go with Option1 above then we don’t need separate SBI
implementation ID for EDK2.

Let us know what you guys think in this context.

Regards,
Anup

From: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>; Anup Patel <Anup.Patel@...>;
Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

This is the PR according to the discussion we had in mail
thread. However you may see some confusions from this change.
https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4

EDK2 is a SBI implementation? Actually edk2 is not one of
the SBI implementations, edk2 fully compliant with OpenSBI
and additionally provides the firmware code base SBI
extension.
We can explain this in the external Firmware code base SBI
extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI
implementation actually goes alone with SBI OpenSBI
implementation.

What is the SBI implementation version associated with EDK2
SBI implementation? This is another confusion because the
major SBI implementation is OpenSBI.
We also can explain this in the external Firmware code base
SBI extension spec, says edk2 SBI implementation version is
the version of SBI OpenSBI implementation.



Apart from the above proposal, can we have more clear
definitions for Firmware code base SBI extension in SBI spec
instead of fixing those confusions in the extern spec? The
below proposal makes more sense?
Define another table for firmware code base, e.g. SBI
Firmware Code Base ID. In the table we can have edk2, uboot,
Coreboot and etc..
Create a new SBI Base function,
sbi_get_firmware_code_base_id() which returns the SBI
Firmware Code Base ID.
Create a new SBI Base function,
sbi_get_firmware_code_base_version() for the version control
of firmware code base SBI extension
Firmware code base SBI extension is from 0xA000000 to
0xAffffff with Firmware Code Base ID in low bits.


I feel the later one makes more sense and clear, how do you
think?
Abner



From: tech-unixplatformspec@... [mailto:
tech-unixplatformspec@...] On Behalf Of Abner
Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <
behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

Cool. This works for edk2. I will have another PR for this.

For edk2, we will request a new SBI implementation ID (4) and
register firmware code base extension SBI in edk2 SEC phase.


From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

I agree with Jonathan's proposal. Let's have SBI FW extension
ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot
extension.

Regards,
Anup

Sent from Outlook Mobile

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> on behalf of Jonathan
Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@... <
tech-unixplatformspec@...>; Anup Patel <
Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

What I was suggesting is something like:

Implementation specific SBI extension Space, Extension IDs
0x0A000000 through 0x0AFFFFFF. Low bits from SBI
Implementation ID.

In this scheme, each SBI implementation would have one
extension reserved for it: BBL gets 0x0A000000, OpenSBI gets
0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc.
That might not seem like a lot of space, but each extension
can have up to 2^32 different functions (including ones for
version number discovery, etc.) so it shouldn't actually be
limiting.

As a side note, I don't think edk2 has an SBI Implementation
ID assigned yet. You should just be able to ask for one and
get it.

Jonathan

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...> wrote:

-----Original Message-----
From: tech-unixplatformspec@... [mailto:tech-
unixplatformspec@...] On Behalf Of Atish
Patra
Sent: Friday, April 10, 2020 11:32 AM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>;
behrensj@...
Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...
; tech-
unixplatformspec@...; Anup Patel <
Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI
extension space for firmware code base implementation

On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS
SW/FW
Technologist) wrote:
Got it, Software ML removed.

Johnathan, do you mean to define it as below?
Firmware Base Extension, Extension ID: 0xxxxxxxxx
(FWBE) , and the
SBI functions definition is firmware code base
implementation-
specific.
I prefer this one as well. But you should pick any value
within experimental
range.
Not quite follow this, why pick up one from experimental
range? The extension ID must be in the range of 0x0800000-
0x08ffffff?

I am not sure about the purpose of the extension but if it
has the
potential to be a generic SBI extension for firmwares,
you should propose it
to the Unix Platform working group. We can add it to the
official spec.
For those SBI extension which is generic to all firmware
code bases, then we should just propose it to the official
SBI spec and don’t not have to go with Firmware Base
Extension.
Firmware Base Extension is classified to those firmware
code base specific SBI, for example to load an edk2 driver
into M-mode managed memory and executed in M-mode which is
behaved as secured system manage mode driver. So the detail
Firmware Base Extension would be defined in the separate
spec and not part of official sbi spec. Occupied an SBI
extension ID is to avoid conflicts.


This also works for me and better than to reserve a
range of IDs.
Thanks
Abner

From: software@... [mailto:
software@...] On
Behalf Of Jonathan Behrens
Sent: Friday, April 10, 2020 12:39 AM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Anup Patel
<anup.patel@...
; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>;
software@...;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [software] Add SBI extension
space for firmware
code base implementation

I think tech-unixplatformspec@... might be
the right list?

To address the PR itself, I'd personally prefer to have
this space
allocated based on SBI implementation IDs analogously
to how the
vendor space is allocated. It also probably makes sense
to pick a
different address range so experimental extension space
doesn't have
to move.

Jonathan

On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via
lists.riscv.org <
abner.chang=hpe.com@...> wrote:
Seems opensbi ML is no longer exist? Use
software@...
insrtead.

From: Chang, Abner (HPS SW/FW Technologist)
Sent: Thursday, April 9, 2020 4:23 PM
To: Atish Patra <Atish.Patra@...>; Anup Patel <
anup.patel@...>
Cc: opensbi@...; Schaefer, Daniel
(DualStudy) <
daniel.schaefer@...>
Subject: Add SBI extension space for firmware code
base
implementation

Hi Atish and Anup,
We are working on some edk2-specific SBI extension
which intends to
be used by upper layer edk2 drivers. We originally
consider to use
Vendor Extension space however vendor may have its
own proprietary
SBI extension as well. In order to prevent from the
conflicts of SBI
extension space, we propose to have a range for
firmware code base.
The changes look like the PR below,

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

How do you think?
Thanks
Abner
--
Regards,
Atish

Kindly send the proposal to the mailing list. We have enough topics now
that we can schedule a meeting to finalize things.


--
Regards,
Atish


Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

Abner Chang <abner.chang@...>
 

Thanks Anup and Atish,

Just wondering the way to submit the changes for adding firmware code base SBI extension space to riscv-sbi-doc. I already had a PR on Github, we can discuss this in the meeting.

-----Original Message-----
From: Atish Patra [mailto:Atish.Patra@...]
Sent: Wednesday, April 22, 2020 5:29 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
behrensj@...; Anup Patel <Anup.Patel@...>
Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-
unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI
extension space for firmware code base implementation

On Tue, 2020-04-21 at 04:45 +0000, Anup Patel wrote:
For riscv-sbi-doc, we have not finalized mailing list based review OR
Github PR based review so most of usl are sending riscv-sbi-doc
changes as patches to mailing list and Github PR.

Regards,
Anup

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 21 April 2020 08:26
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <
behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add
SBI extension space for firmware code base implementation

We would like to have firmware code base SBI based on OpenSBI
implementation ID, because edk2 is not one of the implementations of
SBI. I saw the patches of overriding SBI implementation ID was also
committed. EDK2 still has chance to override the ID to avoid any
conflicts if it is a case.

BTW, the changes made on riscv-sbi-doc should go through the mail list
for review or PR is good?

From: Anup Patel [mailto:Anup.Patel@...]
Sent: Tuesday, April 14, 2020 1:25 PM
To: Jonathan Behrens <behrensj@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
Atish
Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add
SBI extension space for firmware code base implementation

As-per my understanding, U-Boot and Coreboot don’t need this SBI
firmware code base extension. Other SBI extensions are sufficient for
these bootloaders.

In my opinion, use of SBI firmware code base extension should be last
resort (when we have no other way) because this extension adds SBI
implementation specific code in S-mode software. The EDK2 developers
want to use SBI firmware code base extension in their own S-mode
booting stage so we are fine in-context of EDK2.

Also, we are certainly fine if EDK2 want their own SBI implementation
ID and to facilitate OpenSBI can provide API to override SBI
implementation ID which EDK2 can use. Finally, it’s EDK2 developer’s
choice.

Regards,
Anup

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> On Behalf Of Jonathan Behrens
Sent: 14 April 2020 09:50
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add
SBI extension space for firmware code base implementation

Anup wrote:
With EDK2 + OpenSBI running in background, the S-mode software will
see SBI implementation ID of OpenSBI because EDK2 uses unmodified
OpenSBI as library. This means from S-mode perspective the
underlying SBI implementation is still OpenSBI.

But EDK2 can and will register extensions with OpenSBI, meaning that
even identical OpenSBI versions might behave differently with regards
to such extension. So far I think you are right that S-mode won't
actually care about the difference. But I fear that this could end up
like User Agent Strings in web browsers where everybody lies and
claims they're basically the same as OpenSBI so they report the same
implementation ID.

The OpenSBI itself does not need the SBI firmware code base
extension hence I suggested that EDK2 can use ext_id = 0xA000000 +
opensbi_imp_id.

Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI
FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code
extension won’t be available because OpenSBI firmwares will not
implement it.

Are you saying that you are or aren't OK with U-Boot or Coreboot
hypothetically using ext_id = 0xA000000 + opensbi_imp_id to design
their own incompatible extensions? As Abner points out below, it would
probably be fine even if there were incompatible extensions with the
same ID, but I'm trying to understand if that's what you intend. (My
own opinion is that with 2^32 possible IDs it would be preferable to
try to keep them distinct)

Apart from bootloaders, the SBI firmware code base extension space
can be used hypervisors to provide hypervisor specific SBI calls.

Agreed. I think this reservation will prove to be very useful going
forward.

Jonathan

Regards,
Anup

From: Jonathan Behrens <behrensj@...>
Sent: 14 April 2020 08:42
To: Anup Patel <Anup.Patel@...>
Cc: Abner Chang <abner.chang@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software]
Add SBI extension space for firmware code base implementation

Anup, are you saying that EDK2's extension would be the only use of
ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses
OpenSBI is free to make a (potentially incompatible) extension using
that ID?

Jonathan

On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...>
wrote:
Hi Abner,

Yes, your understanding is correct.

The 0xA000000 + opensbi_imp_id is the SBI Firmware code base
extension meant to be used by OpenSBI.

Now EDK2 uses unmodified OpenSBI as library/submodule so
underlying SBI implementation in-case of EDK2 is indeed OpenSBI
itself.

From OpenSBI perspective, we don’t see any OpenSBI specific SBI
calls being implemented in-future because previous and next
booting stages are totally black-box for OpenSBI. This means SBI
Firmware code base extension will be never used by OpenSBI hence
EDK2 can certainly register custom SBI extension for ext_id =
0xA000000 + opensbi_imp_id (Note: EDK2 can use
sbi_ecall_register_extension() API for this from platform
final_init() callback).

Apart from above, I do see SBI firmware code base extension useful
to some of the hypervisors (such as Xvisor, Xen, etc) but this is
in totally different context.

Regards,
Anup

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> On Behalf Of Abner Chang
Sent: 13 April 2020 08:45
To: Jonathan Behrens <behrensj@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software]
Add SBI extension space for firmware code base implementation



From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, April 13, 2020 10:49 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Anup Patel <Anup.Patel@...>; Atish Patra <
Atish.Patra@...>; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>; tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software]
Add SBI extension space for firmware code base implementation

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the
best and simple solution for now.

That is fine, just realize that if you are using OpenSBI's
implementation ID then you need to get approval from them before
defining the extension.
[Abner] I suppose the intention of reserving 0xa000000 is to let
firmware defines its own SBI functions. SBI spec won’t touch or
specify anything in this range as it doesn’t touch vendor
extension. To have 0xa000000 + opensbi_imp_id means the firmware
code base extension is defined base on OpenSBI SBI implementation.

Anup, is my understanding correct?
Abner


Jonathan

On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <
abner.chang=hpe.com@...> wrote:
Basically OpenSBI is a git submodule of edk2 and we don’t make
any modification on it, we just build OpenSBI on edk2 build
environment.
Yes, edk2 will have its own control of extensions for those
firmware code base specific functions. One think we concern
about is the conflict of extension ID with vendor extension.

Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the
best and simple solution for now. We don’t have to add edk2 as
one of SBI implementation and this can also prevent from
extension ID conflict with vendor’s ones.
We can just take #1 opinion.

Any other comments?

Will let you know if we miss something later. Thanks to all for
supporting ekd2.
Abner

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Sunday, April 12, 2020 10:19 PM
To: Anup Patel <Anup.Patel@...>
Cc: Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>
; Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

Is the code for the extension you want to add going to live in
the OpenSBI repository or in the EDK2 repository? If I
understand correctly, it would live in the EDK2 repository,
meaning that your implementation would actually be downstream
from OpenSBI and should have its own implementation ID. If you
did this then it seems like everything else would fall out
nicely: you could decide on version numbers independently of
OpenSBI, there'd be no need for a separate set of firmware IDs,
and you'd have full control over all the details of your
extension.

Jonathan

On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...>
wrote:
Hi Abner,

We have two options here:
EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension
OpenSBI provides a way to EDK2 for overriding SBI
implementation ID (preferably using some API)

If we go with Option1 above then we don’t need separate SBI
implementation ID for EDK2.

Let us know what you guys think in this context.

Regards,
Anup

From: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>
Sent: 12 April 2020 14:50
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>; Anup Patel <Anup.Patel@...>;
Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

This is the PR according to the discussion we had in mail
thread. However you may see some confusions from this change.
https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23
c64f7a6a4be47d6d0ca852433107f6cf4

EDK2 is a SBI implementation? Actually edk2 is not one of the
SBI implementations, edk2 fully compliant with OpenSBI and
additionally provides the firmware code base SBI extension.
We can explain this in the external Firmware code base SBI
extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI
implementation actually goes alone with SBI OpenSBI
implementation.

What is the SBI implementation version associated with EDK2
SBI implementation? This is another confusion because the
major SBI implementation is OpenSBI.
We also can explain this in the external Firmware code base
SBI extension spec, says edk2 SBI implementation version is
the version of SBI OpenSBI implementation.



Apart from the above proposal, can we have more clear
definitions for Firmware code base SBI extension in SBI spec
instead of fixing those confusions in the extern spec? The
below proposal makes more sense?
Define another table for firmware code base, e.g. SBI
Firmware Code Base ID. In the table we can have edk2, uboot,
Coreboot and etc..
Create a new SBI Base function,
sbi_get_firmware_code_base_id() which returns the SBI Firmware
Code Base ID.
Create a new SBI Base function,
sbi_get_firmware_code_base_version() for the version control
of firmware code base SBI extension Firmware code base SBI
extension is from 0xA000000 to 0xAffffff with Firmware Code
Base ID in low bits.


I feel the later one makes more sense and clear, how do you
think?
Abner



From: tech-unixplatformspec@... [mailto:
tech-unixplatformspec@...] On Behalf Of Abner
Chang
Sent: Saturday, April 11, 2020 12:08 AM
To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <
behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

Cool. This works for edk2. I will have another PR for this.

For edk2, we will request a new SBI implementation ID (4) and
register firmware code base extension SBI in edk2 SEC phase.


From: Anup Patel [mailto:Anup.Patel@...]
Sent: Friday, April 10, 2020 11:14 PM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>; Jonathan Behrens <behrensj@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

I agree with Jonathan's proposal. Let's have SBI FW extension
ID depend on SBI implementation ID.

We can target this for SBI v0.3 spec along with System Reboot
extension.

Regards,
Anup

Sent from Outlook Mobile

From: tech-unixplatformspec@... <
tech-unixplatformspec@...> on behalf of Jonathan
Behrens <behrensj@...>
Sent: Friday, April 10, 2020 7:14:45 PM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel
(DualStudy) <daniel.schaefer@...>;
tech-unixplatformspec@... <
tech-unixplatformspec@...>; Anup Patel <
Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI extension space for firmware code base
implementation

What I was suggesting is something like:

Implementation specific SBI extension Space, Extension IDs
0x0A000000 through 0x0AFFFFFF. Low bits from SBI
Implementation ID.

In this scheme, each SBI implementation would have one
extension reserved for it: BBL gets 0x0A000000, OpenSBI gets
0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc.
That might not seem like a lot of space, but each extension
can have up to 2^32 different functions (including ones for
version number discovery, etc.) so it shouldn't actually be
limiting.

As a side note, I don't think edk2 has an SBI Implementation
ID assigned yet. You should just be able to ask for one and
get it.

Jonathan

On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...> wrote:

-----Original Message-----
From: tech-unixplatformspec@... [mailto:tech-
unixplatformspec@...] On Behalf Of Atish
Patra
Sent: Friday, April 10, 2020 11:32 AM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>;
behrensj@...
Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...
; tech- unixplatformspec@...; Anup Patel <
Anup.Patel@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V]
[software] Add SBI
extension space for firmware code base implementation

On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS
SW/FW
Technologist) wrote:
Got it, Software ML removed.

Johnathan, do you mean to define it as below?
Firmware Base Extension, Extension ID: 0xxxxxxxxx
(FWBE) , and the
SBI functions definition is firmware code base
implementation-
specific.
I prefer this one as well. But you should pick any value
within experimental
range.
Not quite follow this, why pick up one from experimental
range? The extension ID must be in the range of 0x0800000-
0x08ffffff?

I am not sure about the purpose of the extension but if it
has the
potential to be a generic SBI extension for firmwares,
you should propose it
to the Unix Platform working group. We can add it to the
official spec.
For those SBI extension which is generic to all firmware
code bases, then we should just propose it to the official
SBI spec and don’t not have to go with Firmware Base
Extension.
Firmware Base Extension is classified to those firmware code
base specific SBI, for example to load an edk2 driver into
M-mode managed memory and executed in M-mode which is
behaved as secured system manage mode driver. So the detail
Firmware Base Extension would be defined in the separate
spec and not part of official sbi spec. Occupied an SBI
extension ID is to avoid conflicts.


This also works for me and better than to reserve a
range of IDs.
Thanks
Abner

From: software@... [mailto:
software@...] On
Behalf Of Jonathan Behrens
Sent: Friday, April 10, 2020 12:39 AM
To: Chang, Abner (HPS SW/FW Technologist) <
abner.chang@...>
Cc: Atish Patra <Atish.Patra@...>; Anup Patel
<anup.patel@...
; Schaefer, Daniel (DualStudy) <
daniel.schaefer@...>;
software@...;
tech-unixplatformspec@...
Subject: Re: [RISC-V] [software] Add SBI extension
space for firmware
code base implementation

I think tech-unixplatformspec@... might be
the right list?

To address the PR itself, I'd personally prefer to have
this space
allocated based on SBI implementation IDs analogously
to how the
vendor space is allocated. It also probably makes sense
to pick a
different address range so experimental extension space
doesn't have
to move.

Jonathan

On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via
lists.riscv.org <
abner.chang=hpe.com@...> wrote:
Seems opensbi ML is no longer exist? Use
software@...
insrtead.

From: Chang, Abner (HPS SW/FW Technologist)
Sent: Thursday, April 9, 2020 4:23 PM
To: Atish Patra <Atish.Patra@...>; Anup Patel <
anup.patel@...>
Cc: opensbi@...; Schaefer, Daniel
(DualStudy) <
daniel.schaefer@...>
Subject: Add SBI extension space for firmware code
base
implementation

Hi Atish and Anup,
We are working on some edk2-specific SBI extension
which intends to
be used by upper layer edk2 drivers. We originally
consider to use
Vendor Extension space however vendor may have its
own proprietary
SBI extension as well. In order to prevent from the
conflicts of SBI
extension space, we propose to have a range for
firmware code base.
The changes look like the PR below,

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

How do you think?
Thanks
Abner
--
Regards,
Atish

Kindly send the proposal to the mailing list. We have enough topics now that
we can schedule a meeting to finalize things.


--
Regards,
Atish


Re: [PATCH v3] Add system reboot extension

Anup Patel
 

-----Original Message-----
From: Bin Meng <bmeng.cn@...>
Sent: 06 April 2020 17:26
To: Anup Patel <Anup.Patel@...>
Cc: tech-unixplatformspec@...; Atish Patra
<Atish.Patra@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v3] Add system reboot
extension

On Mon, Apr 6, 2020 at 11:27 AM Anup Patel <anup.patel@...> wrote:

This patch adds SBI v0.2 compliant system reboot extension. It defines
the sbi_system_reboot function which does different things based on
reboot_type parameter:
1. shutdown - Power-off the entire system
2. cold reboot - Power-cycle the entire system 3. warm reboot -
Power-cycle only parts of system based on SOC vendor
design choices

The sbi_system_reboot function defined here is also a replacement of
SBI v0.1 shutdown function.

Signed-off-by: Atish Patra <atish.patra@...>
Signed-off-by: Anup Patel <anup.patel@...>
---
riscv-sbi.adoc | 47
+++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
A general comment: it would be good to put the reason why a new
extension is introduced, to solve what issue.

Reviewed-by: Bin Meng <bmeng.cn@...>
As suggested on GitHub PR, I will rename SBI extension to "System reset
extension" where Shutdown and Reboot are types of system reset.

Regards,
Anup


[PATCH v4] Add system reset extension

Anup Patel
 

This patch adds SBI v0.2 compliant system reset extension. It defines
the sbi_system_reset function which does different things based on
reset_type parameter:
1. shutdown - Power-off the entire system
2. cold reboot - Power-cycle the entire system
3. warm reboot - Power-cycle only parts of system based on SOC vendor
design choices

The sbi_system_reset function defined here is also a replacement of
SBI v0.1 shutdown function.

Signed-off-by: Atish Patra <atish.patra@...>
Signed-off-by: Anup Patel <anup.patel@...>
Reviewed-by: Bin Meng <bmeng.cn@...>
---
riscv-sbi.adoc | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index 8137686..a1353ac 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -615,6 +615,53 @@ state of the hart at the time of return value verification.
| sbi_hart_get_status | 2 | 0x48534D
|===

+== System Reset Extension, Extension ID: 0x53525354 (SRST)
+
+The System Reset Extension provides a function that allow the supervisor
+software to request system-level reboot or shutdown.
+
+[source, C]
+----
+struct sbiret sbi_system_reset(unsigned long reset_type)
+----
+
+Reset the system based on provided reset_type. This is a synchronous call
+and does not return if it succeeds.
+
+The reset_type parameter is 32 bit wide and has following possible values:
+
+[cols="<,>",options="header,compact"]
+|===
+| Value | Description
+| 0x00000000 | Shutdown
+| 0x00000001 | Cold reboot
+| 0x00000002 | Warm reboot
+| 0x00000003 - 0xEFFFFFFF | Reserved for future use
+| 0xF0000000 - 0xFFFFFFFF | Vendor or platform specific reset type
+| 0x100000000 - 2^XELN-1 | Reserved and unusable on RV32
+|===
+
+Cold reboot results in complete power cycle of the entire system while warm
+reboot depends on SOC vendor design choices.
+
+*Returns* one of the following possible SBI error codes through sbiret.error
+upon failure.
+
+[cols="<,>",options="header,compact"]
+|===
+| Error code | Description
+| SBI_ERR_INVALID_PARAM | `reset_type` is not valid.
+| SBI_ERR_FAILED | Reset request failed for unknown reasons.
+|===
+
+=== SRST Function Listing
+
+[cols="<,,>",options="header,compact"]
+|===
+| Function Name | Function ID | Extension ID
+| sbi_system_reset | 0 | 0x53525354
+|===
+
== Experimental SBI Extension Space, Extension IDs 0x0800000 through 0x08FFFFFF

No management.
--
2.25.1


[PATCH] Clarify VMID consideration for SBI HFENCE VVMA calls

Anup Patel
 

The SBI HFENCE VVMA calls use current VMID (in HGATP CSR) of calling
HART for flushing TLB enteries. This fact is not clearly evident in
current documentatation of HFENCE VVMA calls hence this patch improves
documentation accordingly.

Signed-off-by: Anup Patel <anup.patel@...>
---
riscv-sbi.adoc | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index 8137686..dae489c 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -466,8 +466,8 @@ struct sbiret sbi_remote_hfence_vvma_asid(unsigned long hart_mask,
----
Instruct the remote harts to execute one or more HFENCE.VVMA instructions,
covering the range of guest virtual addresses between start and size for the
-given guest ASID. This function call is only valid for harts implementing
-hypervisor extension.
+given ASID and current VMID (in HGATP CSR) of calling hart. This function call
+is only valid for harts implementing hypervisor extension.

*Returns* following possible values via sbiret.
[cols="<,>",options="header,compact"]
@@ -486,9 +486,9 @@ struct sbiret sbi_remote_hfence_vvma(unsigned long hart_mask,
unsigned long start_addr, unsigned long size)
----
Instruct the remote harts to execute one or more HFENCE.VVMA instructions,
-covering the range of guest virtual addresses between start and size for any
-process belonging to the current guest. This function call is only valid for
-harts implementing hypervisor extension.
+covering the range of guest virtual addresses between start and size for
+current VMID (in HGATP CSR) of calling hart. This function call is only valid
+for harts implementing hypervisor extension.

*Returns* following possible values via sbiret.
[cols="<,>",options="header,compact"]
--
2.25.1


SBI Error codes

Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
 

Hi all,

The SBI spec defines a standard set of error codes, which SBI functions can
return in case of failure (or success). Each function defined in the SBI spec
also defines which error codes it returns in which cases.

My question is:
Can an SBI implementation deviate from these error codes or do the SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard error codes
for the listed cases but can return additional error codes for other
non-specified cases?

I'm talking only about the standardized functions. Functions in the vendor
extension and proposed firmware extension could of course do whatever they
want.

Btw. I think we should mention in the riscv-sbi-doc repo, that this ML is the place to discuss SBI.
(It is, right?)

- Daniel


Re: SBI Error codes

Jonathan Behrens <behrensj@...>
 

I'd argue that standard functions should only be allowed to return the error codes specifically listed in their descriptions (or SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier for users of the API if they can know in advance what errors could be returned. This is the way I interpreted the current spec, though clarification might be worthwhile.

Jonathan

On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) via lists.riscv.org <daniel.schaefer=hpe.com@...> wrote:

Hi all,

The SBI spec defines a standard set of error codes, which SBI functions can
return in case of failure (or success). Each function defined in the SBI spec
also defines which error codes it returns in which cases.

My question is:
Can an SBI implementation deviate from these error codes or do the SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard error codes
for the listed cases but can return additional error codes for other
non-specified cases?

I'm talking only about the standardized functions. Functions in the vendor
extension and proposed firmware extension could of course do whatever they
want.

Btw. I think we should mention in the riscv-sbi-doc repo, that this ML is the place to discuss SBI.
(It is, right?)

- Daniel



Re: SBI Error codes

Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
 

On 5/17/20 5:20 PM, Jonathan Behrens wrote:
I'd argue that standard functions should only be allowed to return the error codes specifically listed in their descriptions (or SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier for users of the API if they can know in advance what errors could be returned. This is the way I interpreted the current spec, though clarification might be worthwhile.
Jonathan
On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
Hi all,
The SBI spec defines a standard set of error codes, which SBI
functions can
return in case of failure (or success). Each function defined in the
SBI spec
also defines which error codes it returns in which cases.
My question is:
Can an SBI implementation deviate from these error codes or do the
SBI ecalls
have to return the standardized error codes, no more, no less?
If they can, in which way? Do they have to implement the standard
error codes
for the listed cases but can return additional error codes for other
non-specified cases?
I'm talking only about the standardized functions. Functions in the
vendor
extension and proposed firmware extension could of course do
whatever they
want.
Btw. I think we should mention in the riscv-sbi-doc repo, that this
ML is the place to discuss SBI.
(It is, right?)
- Daniel
Yes, my thinking, too. I created a PR with my proposed additions to the spec: https://github.com/riscv/riscv-sbi-doc/pull/51

Inline here also:


Every function defined in the specification has a set of error codes associated with a case in which they are returned. In the even of such a case, that error code must be returned. Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification.

Custom SBI calls defined in a vendor or firmware extension can return custom error codes, however it is recommended that they use the standard error codes when appropriate.

- Daniel


Re: SBI Error codes

Jonathan Behrens <behrensj@...>
 

Is it really necessary to include "Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification." ? This empowers an implementation to return ERR_FAILED whenever it doesn't feel like executing a function. In the extreme case, you could have an empty implementation that declared "function unimplemented" to be a case that is unaccounted for by the spec, and just returned failure for literally every call. It also isn't clear to me how a supervisor is meant to respond to getting one of these errors. Should it retry until it gets success? Issue a kernel panic? Something else?

Jonathan


On Sun, May 17, 2020 at 2:21 PM Daniel Schaefer <daniel.schaefer@...> wrote:
On 5/17/20 5:20 PM, Jonathan Behrens wrote:
> I'd argue that standard functions should only be allowed to return the
> error codes specifically listed in their descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier
> for users of the API if they can know in advance what errors could be
> returned. This is the way I interpreted the current spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
>
>     Hi all,
>
>     The SBI spec defines a standard set of error codes, which SBI
>     functions can
>     return in case of failure (or success). Each function defined in the
>     SBI spec
>     also defines which error codes it returns in which cases.
>
>     My question is:
>     Can an SBI implementation deviate from these error codes or do the
>     SBI ecalls
>     have to return the standardized error codes, no more, no less?
>     If they can, in which way? Do they have to implement the standard
>     error codes
>     for the listed cases but can return additional error codes for other
>     non-specified cases?
>
>     I'm talking only about the standardized functions. Functions in the
>     vendor
>     extension and proposed firmware extension could of course do
>     whatever they
>     want.
>
>     Btw. I think we should mention in the riscv-sbi-doc repo, that this
>     ML is the place to discuss SBI.
>     (It is, right?)
>
>     - Daniel

Yes, my thinking, too. I created a PR with my proposed additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51

Inline here also:


Every function defined in the specification has a set of error codes
associated with a case in which they are returned. In the even of such a
case, that error code must be returned. Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification.

Custom SBI calls defined in a vendor or firmware extension can return
custom error codes, however it is recommended that they use the standard
error codes when appropriate.

- Daniel


Re: SBI Error codes

Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
 

Hi Abner and Jonathan,

you're right. I included that sentence to give the implementor a way out,
if the spec doesn't cover a particular case. Now I understand that this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.

Has anybody thought about an SBI testing tool to make sure an implementation
conforms to the spec? Should be doable by hooking QEMU.

Here's the updated text:

    Every function defined in the specification has a set of error codes
    associated with a case in which they are returned. In the even of such a
    case, that error code must be returned. No other error code must be returned.

    Custom SBI calls defined in a vendor or firmware extension can return
    custom error codes, however it is recommended that they use the standard
    error codes when appropriate.

Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used all of the
keywords correctly?

[1] https://tools.ietf.org/html/rfc2119

- Daniel

On 5/18/20 3:42 AM, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Daniel,

It is no necessary to mention that sentence, instead we should well define the error codes returned from all sbi function, as you said no more, no less.

that says we shouldn’t have unaccounted cases with a unclear error code defined in sbi function. The sbi function is not just a guidance to sbi implementation, it could be also a criteria for SBI testing tool to validate the error code return from the implementation of sbi function.

Right?

 

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, May 18, 2020 5:56 AM
To: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] SBI Error codes

 

Is it really necessary to include "Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification." ? This empowers an implementation to return ERR_FAILED whenever it doesn't feel like executing a function. In the extreme case, you could have an empty implementation that declared "function unimplemented" to be a case that is unaccounted for by the spec, and just returned failure for literally every call. It also isn't clear to me how a supervisor is meant to respond to getting one of these errors. Should it retry until it gets success? Issue a kernel panic? Something else?

 

Jonathan

 

On Sun, May 17, 2020 at 2:21 PM Daniel Schaefer <daniel.schaefer@...> wrote:

On 5/17/20 5:20 PM, Jonathan Behrens wrote:
> I'd argue that standard functions should only be allowed to return the
> error codes specifically listed in their descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier
> for users of the API if they can know in advance what errors could be
> returned. This is the way I interpreted the current spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
>
>     Hi all,
>
>     The SBI spec defines a standard set of error codes, which SBI
>     functions can
>     return in case of failure (or success). Each function defined in the
>     SBI spec
>     also defines which error codes it returns in which cases.
>
>     My question is:
>     Can an SBI implementation deviate from these error codes or do the
>     SBI ecalls
>     have to return the standardized error codes, no more, no less?
>     If they can, in which way? Do they have to implement the standard
>     error codes
>     for the listed cases but can return additional error codes for other
>     non-specified cases?
>
>     I'm talking only about the standardized functions. Functions in the
>     vendor
>     extension and proposed firmware extension could of course do
>     whatever they
>     want.
>
>     Btw. I think we should mention in the riscv-sbi-doc repo, that this
>     ML is the place to discuss SBI.
>     (It is, right?)
>
>     - Daniel

Yes, my thinking, too. I created a PR with my proposed additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51

Inline here also:


Every function defined in the specification has a set of error codes
associated with a case in which they are returned. In the even of such a
case, that error code must be returned. Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification.

Custom SBI calls defined in a vendor or firmware extension can return
custom error codes, however it is recommended that they use the standard
error codes when appropriate.

- Daniel


Re: SBI Error codes

Jonathan Behrens <behrensj@...>
 

I'd be in favor of making sure our use of 'must', 'should', etc. are consistent with that RFC. I also noticed that there's some parts that probably belong in a non-normative conventions chapter. Stuff like "Every SBI function should prefer unsigned long as the data type..." is directed at spec authors, not implementors.

Jonathan

On Mon, May 18, 2020 at 8:06 AM Schaefer, Daniel Helmut (DualStudy) via lists.riscv.org <daniel.schaefer=hpe.com@...> wrote:

Hi Abner and Jonathan,

you're right. I included that sentence to give the implementor a way out,
if the spec doesn't cover a particular case. Now I understand that this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.

Has anybody thought about an SBI testing tool to make sure an implementation
conforms to the spec? Should be doable by hooking QEMU.

Here's the updated text:

    Every function defined in the specification has a set of error codes
    associated with a case in which they are returned. In the even of such a
    case, that error code must be returned. No other error code must be returned.

    Custom SBI calls defined in a vendor or firmware extension can return
    custom error codes, however it is recommended that they use the standard
    error codes when appropriate.

Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used all of the
keywords correctly?

[1] https://tools.ietf.org/html/rfc2119

- Daniel

On 5/18/20 3:42 AM, Chang, Abner (HPS SW/FW Technologist) wrote:

Hi Daniel,

It is no necessary to mention that sentence, instead we should well define the error codes returned from all sbi function, as you said no more, no less.

that says we shouldn’t have unaccounted cases with a unclear error code defined in sbi function. The sbi function is not just a guidance to sbi implementation, it could be also a criteria for SBI testing tool to validate the error code return from the implementation of sbi function.

Right?

 

Abner

 

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, May 18, 2020 5:56 AM
To: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] SBI Error codes

 

Is it really necessary to include "Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification." ? This empowers an implementation to return ERR_FAILED whenever it doesn't feel like executing a function. In the extreme case, you could have an empty implementation that declared "function unimplemented" to be a case that is unaccounted for by the spec, and just returned failure for literally every call. It also isn't clear to me how a supervisor is meant to respond to getting one of these errors. Should it retry until it gets success? Issue a kernel panic? Something else?

 

Jonathan

 

On Sun, May 17, 2020 at 2:21 PM Daniel Schaefer <daniel.schaefer@...> wrote:

On 5/17/20 5:20 PM, Jonathan Behrens wrote:
> I'd argue that standard functions should only be allowed to return the
> error codes specifically listed in their descriptions (or
> SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier
> for users of the API if they can know in advance what errors could be
> returned. This is the way I interpreted the current spec, though
> clarification might be worthwhile.
>
> Jonathan
>
> On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut (DualStudy) wrote:
>
>     Hi all,
>
>     The SBI spec defines a standard set of error codes, which SBI
>     functions can
>     return in case of failure (or success). Each function defined in the
>     SBI spec
>     also defines which error codes it returns in which cases.
>
>     My question is:
>     Can an SBI implementation deviate from these error codes or do the
>     SBI ecalls
>     have to return the standardized error codes, no more, no less?
>     If they can, in which way? Do they have to implement the standard
>     error codes
>     for the listed cases but can return additional error codes for other
>     non-specified cases?
>
>     I'm talking only about the standardized functions. Functions in the
>     vendor
>     extension and proposed firmware extension could of course do
>     whatever they
>     want.
>
>     Btw. I think we should mention in the riscv-sbi-doc repo, that this
>     ML is the place to discuss SBI.
>     (It is, right?)
>
>     - Daniel

Yes, my thinking, too. I created a PR with my proposed additions to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51

Inline here also:


Every function defined in the specification has a set of error codes
associated with a case in which they are returned. In the even of such a
case, that error code must be returned. Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification.

Custom SBI calls defined in a vendor or firmware extension can return
custom error codes, however it is recommended that they use the standard
error codes when appropriate.

- Daniel


Re: SBI Error codes

atishp@...
 

On Mon, 2020-05-18 at 14:05 +0200, Schaefer, Daniel Helmut (DualStudy)
wrote:
Hi Abner and Jonathan,

you're right. I included that sentence to give the implementor a way
out,
if the spec doesn't cover a particular case. Now I understand that
this would
be result in very unpredictable behaviour and invite misuse.
If the spec if broken, we need to fix it.

Has anybody thought about an SBI testing tool to make sure an
implementation
conforms to the spec? Should be doable by hooking QEMU.
Yeah. That would be useful. Patches are welcome!!

Here's the updated text:

Every function defined in the specification has a set of error
codes
associated with a case in which they are returned. In the even of
such a
case, that error code must be returned. No other error code must
be returned.
As discussed in the OpenSBI mailing list, this might not be possible
always. Supervisor software should decide whether it wants to hang the
system or continue in case of an unknown error (i.e. SBI_ERR_FAILED).

Custom SBI calls defined in a vendor or firmware extension can
return
custom error codes, however it is recommended that they use the
standard
error codes when appropriate.

Another thought: We've got some uses of 'must', 'should', ... .
Should we add a reference to RFC2199 [1] and check whether we used
all of the
keywords correctly?

[1] https://tools.ietf.org/html/rfc2119
Yup. That would be nice.

- Daniel

On 5/18/20 3:42 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
Hi Daniel,
It is no necessary to mention that sentence, instead we should well
define the error codes returned from all sbi function, as you said
no more, no less.
that says we shouldn’t have unaccounted cases with a unclear error
code defined in sbi function. The sbi function is not just a
guidance to sbi implementation, it could be also a criteria for SBI
testing tool to validate the error code return from the
implementation of sbi function.
Right?

Abner

From: Jonathan Behrens [mailto:behrensj@...]
Sent: Monday, May 18, 2020 5:56 AM
To: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>
Cc: tech-unixplatformspec@...; Chang, Abner (HPS SW/FW
Technologist) <abner.chang@...>
Subject: Re: [RISC-V] [tech-unixplatformspec] SBI Error codes

Is it really necessary to include "Cases unaccounted for by the
specification should use `SBI_ERR_FAILED` and be added in the next
version of the SBI specification." ? This empowers an
implementation to return ERR_FAILED whenever it doesn't feel like
executing a function. In the extreme case, you could have an empty
implementation that declared "function unimplemented" to be a case
that is unaccounted for by the spec, and just returned failure for
literally every call. It also isn't clear to me how a supervisor is
meant to respond to getting one of these errors. Should it retry
until it gets success? Issue a kernel panic? Something else?

Jonathan

On Sun, May 17, 2020 at 2:21 PM Daniel Schaefer <
daniel.schaefer@...> wrote:
On 5/17/20 5:20 PM, Jonathan Behrens wrote:
I'd argue that standard functions should only be allowed to
return the
error codes specifically listed in their descriptions (or
SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way
easier
for users of the API if they can know in advance what errors
could be
returned. This is the way I interpreted the current spec,
though
clarification might be worthwhile.

Jonathan

On Sun, May 17, 2020 at 7:36 AM Schaefer, Daniel Helmut
(DualStudy) wrote:

Hi all,

The SBI spec defines a standard set of error codes, which
SBI
functions can
return in case of failure (or success). Each function
defined in the
SBI spec
also defines which error codes it returns in which cases.

My question is:
Can an SBI implementation deviate from these error codes or
do the
SBI ecalls
have to return the standardized error codes, no more, no
less?
If they can, in which way? Do they have to implement the
standard
error codes
for the listed cases but can return additional error codes
for other
non-specified cases?

I'm talking only about the standardized functions.
Functions in the
vendor
extension and proposed firmware extension could of course
do
whatever they
want.

Btw. I think we should mention in the riscv-sbi-doc repo,
that this
ML is the place to discuss SBI.
(It is, right?)

- Daniel
Yes, my thinking, too. I created a PR with my proposed additions
to the
spec: https://github.com/riscv/riscv-sbi-doc/pull/51

Inline here also:


Every function defined in the specification has a set of error
codes
associated with a case in which they are returned. In the even of
such a
case, that error code must be returned. Cases unaccounted for by
the
specification should use `SBI_ERR_FAILED` and be added in the
next
version of the SBI specification.

Custom SBI calls defined in a vendor or firmware extension can
return
custom error codes, however it is recommended that they use the
standard
error codes when appropriate.

- Daniel
--
Regards,
Atish


[PATCH 0/1] SBI: Add README

Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
 

From: Daniel Schaefer <git@...>

Hi,

I had opened a PR to SBI for adding a README:
https://github.com/riscv/riscv-sbi-doc/pull/50

And now I'm also posting it here for people who might not have seen
it on GitHub.

It's nice to have a README to explain the context and as a "landing
page" for people who come to the repository.


- Daniel

Daniel Schaefer (1):
Add README

README.adoc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 README.adoc

--
2.26.1


[PATCH 1/1] Add README

Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...>
 

Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
README.adoc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 README.adoc

diff --git a/README.adoc b/README.adoc
new file mode 100644
index 0000000..2c479eb
--- /dev/null
+++ b/README.adoc
@@ -0,0 +1,17 @@
+= RISC-V SBI specification
+
+SBI (Supervisor Binary Interface) is an interface between the Supervisor
+Execution Environment (SEE) and the supervisor. It allows the supervisor to
+execute some privileged operations by using the ecall instruction. Examples of
+SEE and supervisor are: M-Mode and S-Mode on Unix-class platforms, where SBI is
+the only interface between them, as well as the Hypervisor extended-Supervisor
+(HS) and Virtualized Supervisor (VS).
+
+Discussion of SBI occurs on the
+https://lists.riscv.org/g/tech-unixplatformspec[RISC-V Unix Platform Mailing
+list]. It is publicly readable but posting requires being a member of the
+RISC-V Foundation. Any new SBI extension needs to be discussed and approved
+there before being merged.
+
+https://github.com/riscv/opensbi[OpenSBI] is the reference implementation,
+but other implementations exist; see section "SBI Implementation IDs".
--
2.26.1


Re: [PATCH 1/1] Add README

Bin Meng
 

On Thu, May 28, 2020 at 4:54 PM Schaefer, Daniel Helmut (DualStudy)
<daniel.schaefer@...> wrote:

Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
README.adoc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 README.adoc

diff --git a/README.adoc b/README.adoc
new file mode 100644
index 0000000..2c479eb
--- /dev/null
+++ b/README.adoc
@@ -0,0 +1,17 @@
+= RISC-V SBI specification
+
+SBI (Supervisor Binary Interface) is an interface between the Supervisor
+Execution Environment (SEE) and the supervisor. It allows the supervisor to
+execute some privileged operations by using the ecall instruction. Examples of
+SEE and supervisor are: M-Mode and S-Mode on Unix-class platforms, where SBI is
+the only interface between them, as well as the Hypervisor extended-Supervisor
+(HS) and Virtualized Supervisor (VS).
+
+Discussion of SBI occurs on the
+https://lists.riscv.org/g/tech-unixplatformspec[RISC-V Unix Platform Mailing
+list]. It is publicly readable but posting requires being a member of the
+RISC-V Foundation. Any new SBI extension needs to be discussed and approved
+there before being merged.
+
+https://github.com/riscv/opensbi[OpenSBI] is the reference implementation,
+but other implementations exist; see section "SBI Implementation IDs".
--
Reviewed-by: Bin Meng <bin.meng@...>

41 - 60 of 1846