Jonathan Behrens <behrensj@...>
toggle quoted messageShow quoted text
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.
On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...
> -----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@...>;
> 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
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
> > >; 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