Date   

Re: [RISC-V] [tech-aia] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Aaron Durbin
 



On Thu, Aug 4, 2022 at 10:16 AM Sunil V L <sunilvl@...> wrote:
Hi Aaron,

On Thu, Aug 04, 2022 at 09:16:21AM -0600, Aaron Durbin wrote:
> On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:
>
> > Hi All,
> >
> > We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
> > ECRs don't have any dependency on any unfrozen specs.
> > Getting these two ECRs accepted by UEFI forum would help us to enable big
> > chunk of ACPI infrastructure patches for RISC-V.
> >
> >          a) RHCT
> >
> > https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
>
>
> I don't think we should submit this one until we settle on how we convey
> behaviors outside of an ISA string. I suspect that will change so we should
> anticipate that. Right now we have ISA string plus CMO parameters as
> specific RHCT Nodes. Are we concerned about timing on adoption to push this
> in its current form? I ask because I'd rather not have this set in stone
> only for us to quickly come back and say "stop using these fields. we have
> a new node/mechanism to convey this information".  What do you think?

I was under the impression that it is decided not to use the
extension names mentioned in profile spec. Sorry I didn't know you are
still working with TSC to conclude on this.

In that case, let's remove the CMO structure from the RHCT and submit
the ECR. CMO structure is not really mandatory for OS.

>
> I brought up this topic in the TSC meeting this week as I indicated I
> would. I need to work with some others to formalize the direction, but
> that's going to take a little more time.

Right. My preference is, to keep sending multiple revisions of the ECRs
with incremental changes, while making sure we don't obsolete things
fairly quickly as you mentioned. I think removing CMO strucutre helps us
to take care of both requirements. When you get clarity from TSC, we can
add in next revision. What do you think?

Sounds good. As long as we don't annoy anyone with a stream ECR updates to the same table I think that's a fine approach.
 

Thanks
Sunil
>
>
> >
> >          b)MADT RINTC
> >
> > https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
>
>
> Aside from maybe wordsmithing a little more for clarity purposes (based on
> commentary) I think this one seems fine from my standpoint.
>
>
> >
> > Please feel free to provide comments in the document before 08/08.
> > The documents and feedback will be archived in the same folder.
> >
> > Thanks
> > Sunil
> >
> > On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org
> > wrote:
> > > Hi All,
> > >
> > > Thanks a lot for great feedback over last week on the ECRs. I have
> > > created version 2 of the ECRs addressing most of the comments. We will be
> > > discussing this version of the ECRs in this week's meeting. Please
> > > provide your comments in this version of the documents.
> > >
> > > 1) Non-AIA ECRs
> > >         a) RHCT - version 2:
> > >
> > https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
> > >         b)MADT RINTC - version 2:
> > >
> > https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
> > > 2) AIA ECRs
> > >         a)  MADT - AIA RINTC (version 2) :
> > >
> > https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
> > >         b) MADT - AIA IMSIC/APLIC version 2:
> > >
> > https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing
> > >
> > > PoC Code has been updated at same location as earlier.
> > >
> > > Thanks
> > > Sunil
> > >
> > > On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org
> > wrote:
> > > > Hi All,
> > > >
> > > > Please review below Engineering Change Request (ECR) to update the ACPI
> > > > spec for enabling basic ACPI support for RISC-V.
> > > >
> > > > 1) Add INTC structure in MADT Table -
> >
> >
> > > >
> > https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing
> > > >
> > > > 2) Add new RISC-V Hart Capabilities Table (RHCT).
> > > >
> > https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing
> > > >
> > > > 3) Add AIA interrupt controllers in MADT table
> > > >
> > https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing
> > > >
> > > > First two ECRs do not have a dependency on any RVI specs which are not
> > > > frozen. But the third ECR  has a dependency on AIA spec to be frozen.
> > > > Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is
> > frozen.
> > > >
> > > > The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
> > > > platform. Below are links to the source code for the PoC.
> > > > qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
> > > > edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
> > > > edk2-platforms -
> > https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
> > > > linux - https://github.com/ventanamicro/linux/tree/dev-upstream
> > > >
> > > > You can find how to build and test these changes in this link -
> > > >
> > https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel
> > > >
> >
> >
> > > > You can provide the feedback by commenting in the document itself. I am
> > > > hoping to send at least first two ECRs to UEFI forum by 8th August
> > 2022.
> > > > So, appreciate your help to improve these ECRs before 4th August 2022
> > > > (45 days from today).
> > > >
> >
> >
> > > > Feel free to reach out if you have any questions.
> > > >
> >
> >
> > > > Thanks!
> > > > Sunil
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>


Re: [RISC-V] [tech-aia] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Sunil V L
 

Hi Aaron,

On Thu, Aug 04, 2022 at 09:16:21AM -0600, Aaron Durbin wrote:
On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:

Hi All,

We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.

a) RHCT

https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing

I don't think we should submit this one until we settle on how we convey
behaviors outside of an ISA string. I suspect that will change so we should
anticipate that. Right now we have ISA string plus CMO parameters as
specific RHCT Nodes. Are we concerned about timing on adoption to push this
in its current form? I ask because I'd rather not have this set in stone
only for us to quickly come back and say "stop using these fields. we have
a new node/mechanism to convey this information". What do you think?
I was under the impression that it is decided not to use the
extension names mentioned in profile spec. Sorry I didn't know you are
still working with TSC to conclude on this.

In that case, let's remove the CMO structure from the RHCT and submit
the ECR. CMO structure is not really mandatory for OS.


I brought up this topic in the TSC meeting this week as I indicated I
would. I need to work with some others to formalize the direction, but
that's going to take a little more time.
Right. My preference is, to keep sending multiple revisions of the ECRs
with incremental changes, while making sure we don't obsolete things
fairly quickly as you mentioned. I think removing CMO strucutre helps us
to take care of both requirements. When you get clarity from TSC, we can
add in next revision. What do you think?

Thanks
Sunil



b)MADT RINTC

https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing

Aside from maybe wordsmithing a little more for clarity purposes (based on
commentary) I think this one seems fine from my standpoint.



Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.

Thanks
Sunil

On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org
wrote:
Hi All,

Thanks a lot for great feedback over last week on the ECRs. I have
created version 2 of the ECRs addressing most of the comments. We will be
discussing this version of the ECRs in this week's meeting. Please
provide your comments in this version of the documents.

1) Non-AIA ECRs
a) RHCT - version 2:
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC - version 2:
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
a) MADT - AIA RINTC (version 2) :
https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
b) MADT - AIA IMSIC/APLIC version 2:
https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing

PoC Code has been updated at same location as earlier.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org
wrote:
Hi All,

Please review below Engineering Change Request (ECR) to update the ACPI
spec for enabling basic ACPI support for RISC-V.

1) Add INTC structure in MADT Table -

https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

2) Add new RISC-V Hart Capabilities Table (RHCT).
https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

3) Add AIA interrupt controllers in MADT table
https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

First two ECRs do not have a dependency on any RVI specs which are not
frozen. But the third ECR has a dependency on AIA spec to be frozen.
Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is
frozen.

The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
platform. Below are links to the source code for the PoC.
qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
edk2-platforms -
https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
linux - https://github.com/ventanamicro/linux/tree/dev-upstream

You can find how to build and test these changes in this link -
https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

You can provide the feedback by commenting in the document itself. I am
hoping to send at least first two ECRs to UEFI forum by 8th August
2022.
So, appreciate your help to improve these ECRs before 4th August 2022
(45 days from today).

Feel free to reach out if you have any questions.

Thanks!
Sunil















Re: [RISC-V] [tech-aia] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Aaron Durbin
 



On Wed, Aug 3, 2022 at 8:17 AM Sunil V L <sunilvl@...> wrote:
Hi All,

We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.

         a) RHCT
         https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing

I don't think we should submit this one until we settle on how we convey behaviors outside of an ISA string. I suspect that will change so we should anticipate that. Right now we have ISA string plus CMO parameters as specific RHCT Nodes. Are we concerned about timing on adoption to push this in its current form? I ask because I'd rather not have this set in stone only for us to quickly come back and say "stop using these fields. we have a new node/mechanism to convey this information".  What do you think?

I brought up this topic in the TSC meeting this week as I indicated I would. I need to work with some others to formalize the direction, but that's going to take a little more time.
 

         b)MADT RINTC
         https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing

Aside from maybe wordsmithing a little more for clarity purposes (based on commentary) I think this one seems fine from my standpoint. 



Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.

Thanks
Sunil

On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org wrote:
> Hi All,
>
> Thanks a lot for great feedback over last week on the ECRs. I have
> created version 2 of the ECRs addressing most of the comments. We will be
> discussing this version of the ECRs in this week's meeting. Please
> provide your comments in this version of the documents.
>
> 1) Non-AIA ECRs
>         a) RHCT - version 2:
>         https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
>         b)MADT RINTC - version 2:
>         https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
> 2) AIA ECRs
>         a)  MADT - AIA RINTC (version 2) :
>         https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
>         b) MADT - AIA IMSIC/APLIC version 2:
>         https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing

> PoC Code has been updated at same location as earlier.
>
> Thanks
> Sunil
>
> On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:
> > Hi All,
> >
> > Please review below Engineering Change Request (ECR) to update the ACPI
> > spec for enabling basic ACPI support for RISC-V.
> >
> > 1) Add INTC structure in MADT Table -                                                                                                                                                                     
> > https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing
> >
> > 2) Add new RISC-V Hart Capabilities Table (RHCT).
> > https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing
> >
> > 3) Add AIA interrupt controllers in MADT table
> > https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing
> >
> > First two ECRs do not have a dependency on any RVI specs which are not
> > frozen. But the third ECR  has a dependency on AIA spec to be frozen.
> > Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.
> >
> > The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
> > platform. Below are links to the source code for the PoC.
> > qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
> > edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
> > edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
> > linux - https://github.com/ventanamicro/linux/tree/dev-upstream
> >
> > You can find how to build and test these changes in this link -
> > https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel
> >                                                                                                                                                                                                           
> > You can provide the feedback by commenting in the document itself. I am
> > hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
> > So, appreciate your help to improve these ECRs before 4th August 2022
> > (45 days from today).
> >                                                                                                                                                                                                           
> > Feel free to reach out if you have any questions.
> >                                                                                                                                                                                                           
> > Thanks!
> > Sunil
> >
> >
> >
> >
> >
>
>
>
>
>






SBI Debug Console Extension Proposal (Draft v4)

Anup Patel
 

Hi All,

Based on feedback, below is the updated draft proposal of the
SBI Debug Console Extension ...

The motivations behind this proposal is as follows:
1) There is no new SBI extension replacing the legacy SBI v0.1
putchar() and getchar() calls. These legacy SBI v0.1 calls are
now disabled by default in Linux and will be eventually deprecated.
We need a replacement at least for the SBI v0.1 putchar() which
is widely used for early prints in various OSes and Bootloaders.
2) The OS-A Platforms (or SEE) specification need to mandate
a particular type of UART (8250, ns16550, or SiFive) as a standard
way for boot-time early prints in supervisor-mode software. Using
SBI debug console extension, the OS-A Platforms (or SEE)
specifications don't need to mandate any type of UART.
3) The legacy SBI v0.1 putchar() only supports printing one
character at a time. For some of the hypervisors (particularly KVM),
SBI based early prints (i.e. earlycon=sbi) is slow because each
SBI v0.1 putchar() trap will be forwarded to the KVM user-space
(KVMTOOL or QEMU).

In other words, the SBI debug console extension defines a standard
way for boot-time early prints in supervisor-mode software.

We have completed the proof-of-concept implementation of this
SBI extension proposal. Refer, "riscv_sbi_dbcn_v1" branch in the
following repos:
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git
https://github.com/avpatel/kvmtool.git

Please review it and provide your feedback.

Regards,
Anup

SBI Debug Console Extension (EID #0x4442434E "DBCN")
====================================================

The debug console extension defines a generic mechanism for boot
time early prints from supervisor-mode software which allows users
to catch boot-time issues in supervisor-mode software.

This extension replaces the legacy console putchar (EID #0x01)
extension with following improvements:
1) It follows the new calling convention defined by the SBI v1.0
(or higher) specification.
2) It allows supervisor software to print multiple characters
in a single SBI call.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
2) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

If the underlying physical console has extra bits for error checking
(or correction) then these extra bits should be handled by the SBI
implementation.

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long num_chars,
uint64_t base_addr)

Print a specified input string on the debug console.

The `num_chars` parameter specifies the number of characters (or
bytes) in the input string whereas `base_addr` parameter specifies
the physical base address of the input string.

This is a blocking SBI call and will only return after printing all
characters of the input string.

Errors:
SBI_SUCCESS - Characters printed successfully.
SBI_ERR_INVALID_ADDRESS - The string pointed by `num_chars` and `base_addr`
parameters is not entirely accessible to
supervisor-mode.
SBI_ERR_FAILED - Failed to print characters due to I/O errors.


Re: SBI Debug Console Extension Proposal (Draft v3)

Anup Patel
 

Hi,

On Wed, Aug 3, 2022 at 1:27 PM 洛佳 Luo Jia <me@...> wrote:

Hi Group,

I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the
string address in a probable virtual address? In this way the supervisor won't need to convert it to physical
address, and we can save one argument for future designs to refer to. If machine mode firmware need to
read the supervisor accesible address, it uses mstatus.TVM bit to achieve this. By this way the machine
accesses the string parameter the same way the supervisor does.

Considering difference of physical and virtual address spacees (e.g. on RV32 Sv32 has 34-bit physical address),
if the supervisor does not use virtual memory, it only reads lower 32 bit of physical address, which is the
same limit of how machine mode firmware would read the memory.

By this way we have `usize` as parameter:

fn debug_console_print(supervisor_address: usize, length_bytes: usize) -> SbiRet { ... }
There are two major issues in passing virtual address of string:

1) A rogue supervisor software can pass a virtual address mapped to a
physical address not accessible to it.
2) To access a string by virtual address, the SBI implementation (M-mode
firmware and hypervisors) end-up using unpriv load/store instructions.
These unpriv load/store instructions can potentially trap for hypervisor
because the guest OS can swap-out pages while the hypervisor is
trying to access it. Further in-case of nested virtualization, the unpriv
load/store instructions always trap to the host hypervisor so accessing
string by virtual address becomes extremely slow for guest hypervisor.

Due to the above reasons, we avoid using virtual addresses as
parameters in newer SBI calls for SBI v0.2 (higher).

Regards,
Anup


... other than combining different parts to form the final address.

Luo Jia


Re: Review request for ACPI ECRs

Sunil V L
 

Hi All,

We plan to send below two ECRs to UEFI forum on 08/08/2022. These two
ECRs don't have any dependency on any unfrozen specs.
Getting these two ECRs accepted by UEFI forum would help us to enable big
chunk of ACPI infrastructure patches for RISC-V.

a) RHCT
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing

Please feel free to provide comments in the document before 08/08.
The documents and feedback will be archived in the same folder.

Thanks
Sunil

On Tue, Jul 05, 2022 at 10:46:18PM +0530, Sunil V L via lists.riscv.org wrote:
Hi All,

Thanks a lot for great feedback over last week on the ECRs. I have
created version 2 of the ECRs addressing most of the comments. We will be
discussing this version of the ECRs in this week's meeting. Please
provide your comments in this version of the documents.

1) Non-AIA ECRs
a) RHCT - version 2:
https://docs.google.com/document/d/1LlCefO_0GQ_7Tf3lzfMPETEfMlGo2FfLRJ09IMqJKEk/edit?usp=sharing
b)MADT RINTC - version 2:
https://docs.google.com/document/d/1waaAqDyTWvYcCSd1Df-vj0EKCA1nukKF_puclaVYkSo/edit?usp=sharing
2) AIA ECRs
a) MADT - AIA RINTC (version 2) :
https://docs.google.com/document/d/1LBKD1gyi6kOfE3V2WiFOPz1h4MlmxHDj7vkjjfSygBo/edit?usp=sharing
b) MADT - AIA IMSIC/APLIC version 2:
https://docs.google.com/document/d/1zDainvcxD14eawsyc3y1s78zP7ruefyGzcsP1bBak3w/edit?usp=sharing

PoC Code has been updated at same location as earlier.

Thanks
Sunil

On Tue, Jun 21, 2022 at 11:18:02PM +0530, Sunil V L via lists.riscv.org wrote:
Hi All,

Please review below Engineering Change Request (ECR) to update the ACPI
spec for enabling basic ACPI support for RISC-V.

1) Add INTC structure in MADT Table -
https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

2) Add new RISC-V Hart Capabilities Table (RHCT).
https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

3) Add AIA interrupt controllers in MADT table
https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

First two ECRs do not have a dependency on any RVI specs which are not
frozen. But the third ECR has a dependency on AIA spec to be frozen.
Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
platform. Below are links to the source code for the PoC.
qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
linux - https://github.com/ventanamicro/linux/tree/dev-upstream

You can find how to build and test these changes in this link -
https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

You can provide the feedback by commenting in the document itself. I am
hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
So, appreciate your help to improve these ECRs before 4th August 2022
(45 days from today).

Feel free to reach out if you have any questions.

Thanks!
Sunil








Re: SBI Debug Console Extension Proposal (Draft v3)

洛佳 Luo Jia
 

Hi Group,

I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the
string address in a probable virtual address? In this way the supervisor won't need to convert it to physical
address, and we can save one argument for future designs to refer to. If machine mode firmware need to
read the supervisor accesible address, it uses mstatus.TVM bit to achieve this. By this way the machine
accesses the string parameter the same way the supervisor does.

Considering difference of physical and virtual address spacees (e.g. on RV32 Sv32 has 34-bit physical address),
if the supervisor does not use virtual memory, it only reads lower 32 bit of physical address, which is the
same limit of how machine mode firmware would read the memory.

By this way we have `usize` as parameter:

fn debug_console_print(supervisor_address: usize, length_bytes: usize) -> SbiRet { ... }

... other than combining different parts to form the final address.

Luo Jia


Re: SBI Debug Console Extension Proposal (Draft v3)

Anup Patel
 

On Mon, Jul 25, 2022 at 5:11 PM Darius Rad <darius@...> wrote:

On Mon, Jul 25, 2022 at 10:04:52AM +0530, Anup Patel wrote:

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long addr_lo,
unsigned long addr_hi,
unsigned long num_chars)

Print a specified input string on the debug console.

The physical base address and size of the string to be printed is
derived from parameters as follows:
1) `addr_lo` parameter specifies the lower XLEN bits of the string
physical base address.
2) `addr_hi` parameter specifies the string physical base address
right shifted by XLEN.
It is really necessary to have two long parameters for a physical address
on RV64? Clearly this is necessary for RV32, where the maximum physical
address is greater than XLEN, but that is not the case for RV64.

Why not use long long, which is 8 bytes on both RV32 and RV64 (on the
respective ABIs, that is)? Or use a different function signature for RV32
and RV64, with two parameters for the former and one for the latter?
For SBI spec, we have avoided separate function signatures for RV32
and RV64 so better to prefer other options.

If we want to combine "addr_lo" and "addr_hi" into one parameter then
uint64_t is better and consistent with other parts of SBI spec as well.

Regards,
Anup


3) `num_chars` parameter specifies the size of the string as the
number of characters (or bytes).
// darius


Re: SBI Debug Console Extension Proposal (Draft v3)

Darius Rad
 

On Mon, Jul 25, 2022 at 10:04:52AM +0530, Anup Patel wrote:

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long addr_lo,
unsigned long addr_hi,
unsigned long num_chars)

Print a specified input string on the debug console.

The physical base address and size of the string to be printed is
derived from parameters as follows:
1) `addr_lo` parameter specifies the lower XLEN bits of the string
physical base address.
2) `addr_hi` parameter specifies the string physical base address
right shifted by XLEN.
It is really necessary to have two long parameters for a physical address
on RV64? Clearly this is necessary for RV32, where the maximum physical
address is greater than XLEN, but that is not the case for RV64.

Why not use long long, which is 8 bytes on both RV32 and RV64 (on the
respective ABIs, that is)? Or use a different function signature for RV32
and RV64, with two parameters for the former and one for the latter?

3) `num_chars` parameter specifies the size of the string as the
number of characters (or bytes).
// darius


Re: SBI Debug Console Extension Proposal (Draft v3)

Anup Patel
 

On Mon, Jul 25, 2022 at 11:37 AM Heinrich Schuchardt
<heinrich.schuchardt@...> wrote:

On 7/25/22 06:34, Anup Patel wrote:
Hi All,

Based on feedback, below is the updated draft proposal of the
SBI Debug Console Extension ...

The motivations behind this proposal is as follows:
1) There is no new SBI extension replacing the legacy SBI v0.1
putchar() and getchar() calls. These legacy SBI v0.1 calls are
now disabled by default in Linux and will be eventually deprecated.
We need a replacement at least for the SBI v0.1 putchar() which
is widely used for early prints in various OSes and Bootloaders.
2) The OS-A Platforms (or SEE) specification need to mandate
a particular type of UART (8250, ns16550, or SiFive) as a standard
way for boot-time early prints in supervisor-mode software. Using
SBI debug console extension, the OS-A Platforms (or SEE)
specifications don't need to mandate any type of UART.
3) The legacy SBI v0.1 putchar() only supports printing one
character at a time. For some of the hypervisors (particularly KVM),
SBI based early prints (i.e. earlycon=sbi) is slow because each
SBI v0.1 putchar() trap will be forwarded to the KVM user-space
(KVMTOOL or QEMU).

In other words, the SBI debug console extension defines a standard
way for boot-time early prints in supervisor-mode software.

We have completed the proof-of-concept implementation of this
SBI extension proposal. Refer, "riscv_sbi_dbcn_v1" branch in the
following repos:
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git
https://github.com/avpatel/kvmtool.git

Please review it and provide your feedback.

Regards,
Anup

SBI Debug Console Extension (EID #0x4442434E "DBCN")
====================================================

The debug console extension defines a generic mechanism for boot
time early prints from supervisor-mode software which allows users
to catch boot-time issues in supervisor-mode software.

This extension replaces the legacy console putchar (EID #0x01)
extension with following improvements:
1) It follows the new calling convention defined by the SBI v1.0
(or higher) specification.
2) It allows supervisor software to print multiple characters
in a single SBI call.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
2) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

If the underlying physical console has extra bits for error checking
(or correction) then these extra bits should be handled by the SBI
implementation.

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long addr_lo,
unsigned long addr_hi,
unsigned long num_chars)

Print a specified input string on the debug console.

The physical base address and size of the string to be printed is
derived from parameters as follows:
1) `addr_lo` parameter specifies the lower XLEN bits of the string
physical base address.
2) `addr_hi` parameter specifies the string physical base address
right shifted by XLEN.
3) `num_chars` parameter specifies the size of the string as the
number of characters (or bytes).

This is a blocking SBI call and will only return after printing all
characters of the string.

Errors:
SBI_SUCCESS - Characters printed successfully.
SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_lo`, `addr_hi`,
and `num_chars` parameters is not accessible
to supervisor-mode.
We should also cover the case that only a part of the memory area is
accessible by S-mode.

%s/accessible/entirely accessible/
Okay, I will update the text.


It is unclear if the SBI is obliged to check S-mode accessibility. The
specification should explicitly make this check either obligatory or
optional. For security reasons the check should be obligatory on systems
where accessibility can be restricted.
Yes, the accessibility check on physical address parameters is very
important for SBI implementation (M-mode firmware, Hypervisors) to
ensure that supervisor-mode does not provide rouge/inaccessible
address to print from.

For example, a system might have been partitioned into multiple
domains so software running in one domain cannot pass a physical
address belonging to another domain.

Regards,
Anup


Otherwise the specification looks fine to me.

Best regards

Heinrich

SBI_ERR_FAILED - Failed to print characters due to I/O errors.


Re: SBI Debug Console Extension Proposal (Draft v3)

Heinrich Schuchardt
 

On 7/25/22 06:34, Anup Patel wrote:
Hi All,
Based on feedback, below is the updated draft proposal of the
SBI Debug Console Extension ...
The motivations behind this proposal is as follows:
1) There is no new SBI extension replacing the legacy SBI v0.1
putchar() and getchar() calls. These legacy SBI v0.1 calls are
now disabled by default in Linux and will be eventually deprecated.
We need a replacement at least for the SBI v0.1 putchar() which
is widely used for early prints in various OSes and Bootloaders.
2) The OS-A Platforms (or SEE) specification need to mandate
a particular type of UART (8250, ns16550, or SiFive) as a standard
way for boot-time early prints in supervisor-mode software. Using
SBI debug console extension, the OS-A Platforms (or SEE)
specifications don't need to mandate any type of UART.
3) The legacy SBI v0.1 putchar() only supports printing one
character at a time. For some of the hypervisors (particularly KVM),
SBI based early prints (i.e. earlycon=sbi) is slow because each
SBI v0.1 putchar() trap will be forwarded to the KVM user-space
(KVMTOOL or QEMU).
In other words, the SBI debug console extension defines a standard
way for boot-time early prints in supervisor-mode software.
We have completed the proof-of-concept implementation of this
SBI extension proposal. Refer, "riscv_sbi_dbcn_v1" branch in the
following repos:
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git
https://github.com/avpatel/kvmtool.git
Please review it and provide your feedback.
Regards,
Anup
SBI Debug Console Extension (EID #0x4442434E "DBCN")
====================================================
The debug console extension defines a generic mechanism for boot
time early prints from supervisor-mode software which allows users
to catch boot-time issues in supervisor-mode software.
This extension replaces the legacy console putchar (EID #0x01)
extension with following improvements:
1) It follows the new calling convention defined by the SBI v1.0
(or higher) specification.
2) It allows supervisor software to print multiple characters
in a single SBI call.
Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
2) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.
If the underlying physical console has extra bits for error checking
(or correction) then these extra bits should be handled by the SBI
implementation.
Function: Console Puts (FID #0)
-------------------------------
struct sbiret sbi_debug_console_puts(unsigned long addr_lo,
unsigned long addr_hi,
unsigned long num_chars)
Print a specified input string on the debug console.
The physical base address and size of the string to be printed is
derived from parameters as follows:
1) `addr_lo` parameter specifies the lower XLEN bits of the string
physical base address.
2) `addr_hi` parameter specifies the string physical base address
right shifted by XLEN.
3) `num_chars` parameter specifies the size of the string as the
number of characters (or bytes).
This is a blocking SBI call and will only return after printing all
characters of the string.
Errors:
SBI_SUCCESS - Characters printed successfully.
SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_lo`, `addr_hi`,
and `num_chars` parameters is not accessible
to supervisor-mode.
We should also cover the case that only a part of the memory area is accessible by S-mode.

%s/accessible/entirely accessible/

It is unclear if the SBI is obliged to check S-mode accessibility. The specification should explicitly make this check either obligatory or optional. For security reasons the check should be obligatory on systems where accessibility can be restricted.

Otherwise the specification looks fine to me.

Best regards

Heinrich

SBI_ERR_FAILED - Failed to print characters due to I/O errors.


SBI Debug Console Extension Proposal (Draft v3)

Anup Patel
 

Hi All,

Based on feedback, below is the updated draft proposal of the
SBI Debug Console Extension ...

The motivations behind this proposal is as follows:
1) There is no new SBI extension replacing the legacy SBI v0.1
putchar() and getchar() calls. These legacy SBI v0.1 calls are
now disabled by default in Linux and will be eventually deprecated.
We need a replacement at least for the SBI v0.1 putchar() which
is widely used for early prints in various OSes and Bootloaders.
2) The OS-A Platforms (or SEE) specification need to mandate
a particular type of UART (8250, ns16550, or SiFive) as a standard
way for boot-time early prints in supervisor-mode software. Using
SBI debug console extension, the OS-A Platforms (or SEE)
specifications don't need to mandate any type of UART.
3) The legacy SBI v0.1 putchar() only supports printing one
character at a time. For some of the hypervisors (particularly KVM),
SBI based early prints (i.e. earlycon=sbi) is slow because each
SBI v0.1 putchar() trap will be forwarded to the KVM user-space
(KVMTOOL or QEMU).

In other words, the SBI debug console extension defines a standard
way for boot-time early prints in supervisor-mode software.

We have completed the proof-of-concept implementation of this
SBI extension proposal. Refer, "riscv_sbi_dbcn_v1" branch in the
following repos:
https://github.com/avpatel/opensbi.git
https://github.com/avpatel/linux.git
https://github.com/avpatel/kvmtool.git

Please review it and provide your feedback.

Regards,
Anup

SBI Debug Console Extension (EID #0x4442434E "DBCN")
====================================================

The debug console extension defines a generic mechanism for boot
time early prints from supervisor-mode software which allows users
to catch boot-time issues in supervisor-mode software.

This extension replaces the legacy console putchar (EID #0x01)
extension with following improvements:
1) It follows the new calling convention defined by the SBI v1.0
(or higher) specification.
2) It allows supervisor software to print multiple characters
in a single SBI call.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
2) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

If the underlying physical console has extra bits for error checking
(or correction) then these extra bits should be handled by the SBI
implementation.

Function: Console Puts (FID #0)
-------------------------------

struct sbiret sbi_debug_console_puts(unsigned long addr_lo,
unsigned long addr_hi,
unsigned long num_chars)

Print a specified input string on the debug console.

The physical base address and size of the string to be printed is
derived from parameters as follows:
1) `addr_lo` parameter specifies the lower XLEN bits of the string
physical base address.
2) `addr_hi` parameter specifies the string physical base address
right shifted by XLEN.
3) `num_chars` parameter specifies the size of the string as the
number of characters (or bytes).

This is a blocking SBI call and will only return after printing all
characters of the string.

Errors:
SBI_SUCCESS - Characters printed successfully.
SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_lo`, `addr_hi`,
and `num_chars` parameters is not accessible
to supervisor-mode.
SBI_ERR_FAILED - Failed to print characters due to I/O errors.


SBI Debug Trigger Extension Proposal (Draft v4)

Anup Patel
 

Hi All,

To support native debugging in S-mode and VS-mode, we need
a SBI Debug Trigger extension which complements the Sdtrig
extension.

Below is the draft proposal of the SBI Debug Trigger Extension...

Many thanks to folks (CC'ed here) who provided early feedback
and helped improve this proposal.

The proposed SBI extension is highly inspired from Linux HW
breakpoint infrastructure which is built on top of the Linux
perf subsystem.

Please review and provide your feedback.

Regards,
Anup

SBI Debug Trigger Extension (EID #0x44425452 "DBTR")
====================================================

The RISC-V Sdtrig ISA extension allows machine-mode software to
directly configure debug triggers which in-turn allows native
(or hosted) debugging without any external debugger.

The SBI debug trigger extension defines a SBI based abstraction to
provide native debugging for supervisor-mode software such that it:
1) Suitable for the rich operating systems and hypervisors running
in supervisor-mode.
2) Allows Guest (VS-mode) and Hypervisor (HS-mode) to share debug
triggers on a HART.

Some of the functions defined by this SBI extension have physical
memory as parameters for input and/or output. This physical memory
parameter MUST satisfy following requirements:
1) The base address of the physical memory MUST be 16-byte aligned
so that it is machine word aligned for RV32, RV64 and RV128.
2) The SBI implementation MUST check that the supervisor-mode
software is allowed to read and write the specified physical
memory on the calling HART.
3) The SBI implementation MUST access the specified physical
memory using the PMA attribute.
Note: If the supervisor-mode software access the same physical
memory using memory type different from PMA then a loss of
coherence or unexpected memory ordering may occur and the
invoking software should follow the rules and sequences defined
in the RISC-V Svpbmt specification to prevent the loss of
coherence and memory ordering.

Each debug trigger is assigned a logical number called `trig_idx`
by the SBI implementation. If total number of debug triggers are
`N` then `0 <= trig_idx < N`.

The configuration of each debug trigger is expressed by three
entities `trig_tdata1`, `trig_tdata2`, and `trig_tdata3` which
are same as the `tdata1`, `tdata2`, and `tdata3` CSRs defined by
the RISC-V Sdtrig specification but with the following additional
constraints:
1) The `trig_tdata1.dmode` bit should always be zero.
2) The `trig_tdata1.m` bit should always be zero.
3) The `trig_tdata1.action` bits should always be zero.

The SBI implementation must also maintain an additional software
state for each debug trigger called `trig_state` which is encoded
as follows:
reserved [XLEN-1:5] - Reserved for future use.
vs [4:4] - Saved copy of the `trig_tdata1.vs` bit.
vu [3:3] - Saved copy of the `trig_tdata1.vu` bit.
s [2:2] - Saved copy of the `trig_tdata1.s` bit.
u [1:1] - Saved copy of the `trig_tdata1.u` bit.
mapped [0:0] - When set, the trigger has been mapped to
some HW debug trigger.

Function: Get number of triggers (FID #0)
-----------------------------------------

struct sbiret sbi_debug_num_triggers(unsigned long trig_tdata1)

Get the number of per-HART debug triggers which can support the
trigger configuration specified by `trig_tdata1` parameter.

The SBI implementation must return the total number of per-HART
debug triggers when `trig_tdata1 == 0`.

Returns the number of per-HART debug triggers in `sbiret.value`
and always returns SBI_SUCCESS in `sbiret.error`.

Function: Read triggers (FID #1)
--------------------------------

struct sbiret sbi_debug_read_triggers(unsigned long trig_idx_base,
unsigned long trig_count,
unsigned long out_addr_div_by_16)

Read the trigger state and configuration for a range of debug triggers
specified by `trig_idx_base` and `trig_count` parameters on the calling
HART.

The state and configuration of triggers will be written to an output
memory of size `trig_count * 4 * (XLEN / 8)` bytes. The base physical
address of the output memory right shifted by 4 is specified by the
`out_addr_div_by_16` parameter.

For i'th debug trigger in the specified range, the trigger configuration
consists of four XLEN-bit words written in little-endian format at
`offset = i * 4 * (XLEN / 8)` of the output memory. The contents of
output trigger configuration words are as follows:
word[0] = trig_state
word[1] = trig_tdata1
word[2] = trig_tdata2
word[3] = trig_tdata3

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Configuration read successfully.
SBI_ERR_INVALID_ADDRESS - The physical memory pointed by the
`out_addr_div_by_16` parameter is not
accessible to supervisor-mode.
SBI_ERR_INVALID_PARAM - Either `trig_idx_base + trig_count` or
`trig_idx_base` is greater than the total
number of triggers.

Function: Install triggers (FID #2)
-----------------------------------

struct sbiret sbi_debug_install_triggers(unsigned long trig_count,
unsigned long in_addr_div_by_16,
unsigned long out_addr_div_by_16)

Install debug triggers based on an array of trigger configurations
specified through an input memory and return the `trig_idx` of each
installed debug trigger in an output memory.

The `trig_count` parameter represents the number of debug triggers
to be installed.

The base physical address of the input memory right shifted by 4
is specified by the `in_addr_div_by_16` parameter and the size of
input memory is `trig_count * 4 * (XLEN / 8)` bytes. The i'th input
trigger configuration is at `offset = i * 4 * (XLEN / 8)` of the
input memory consisting of four consecutive XLEN-bit words in
little-endian format. The contents of each trigger configuration
are follows:
word[0] = Reserved for future use and should be zero
word[1] = trig_tdata1
word[2] = trig_tdata2
word[3] = trig_tdata3

The base physical address of the output memory right shifted by
4 is specified by the `out_addr_div_by_16` parameter and the size
of output memory is `trig_count * (XLEN / 8)` bytes. The `trig_idx`
assigned for the i'th input trigger configuration is written at
`offset = i * (XLEN / 8)` of the output memory in little-endian
format.

For each input trigger configuration in the input memory, the SBI
implementation should:
1) Map a free `trig_idx` with an unused HW debug trigger that
matches the trigger configuration.
2) Save a copy of the `trig_tdata1.vs`, `trig_tdata1.vu`,
`trig_tdata1.s`, and `trig_tdata.u` bits in `trig_state`.
3) Update the `tdata1`, `tdata2`, and `tdata3` CSRs of the
HW debug trigger.

Additionally for each input trigger configuration chain, the
SBI implementation MUST assign contiguous `trig_idx` values
and contiguous HW debug triggers when installing debug triggers.

The last trigger configuration in the input memory MUST not have
`trig_tdata1.chain == 1` for `trig_tdata1.type = 2 or 6` to prevent
incomplete trigger configuration chain in input memory.

This function succeeds and output memory is written with `trig_idx`
values only if the SBI implementation is able to install a debug
trigger for each input trigger configuration.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Triggers installed successfully. The
`sbiret.value` will be set to zero.
SBI_ERR_INVALID_ADDRESS - The physical memory pointed by the
`in_addr_div_by_16` or `out_addr_div_by_16`
parameter is not accessible to supervisor-mode.
The `sbiret.value` will be set to zero.
SBI_ERR_INVALID_PARAM - One of the input trigger configuration has
an invalid value. The `sbiret.value` will
be set to the array index of failing input
trigger configuration.
SBI_ERR_NOT_SUPPORTED - One of the input trigger configuration can't
be programmed due to unimplemented optional
bits in `tdata1`, `tdata2`, or `tdata3` CSRs.
The `sbiret.value` will be set to the array
index of failing input trigger configuration.
SBI_ERR_FAILED - Failed to assign `trig_idx` or HW debug
trigger for one of the input trigger
configuration. The `sbiret.value` will be
set to the array index of failing input
trigger configuration.

Function: Uninstall a set of triggers (FID #3)
----------------------------------------------

struct sbiret sbi_debug_uninstall_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Uninstall a set of debug triggers specified by the `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

For each debug trigger in the specified set of debug triggers, the
SBI implementation should:
1) Clear the `tdata1`, `tdata2`, and `tdata3` CSRs of the mapped
HW debug trigger.
2) Clear the `trig_state` of the debug trigger.
3) Unmap the HW debug trigger from `trig_idx` and free both of
them for future trigger installations.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger uninstalled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

Function: Enable a set of triggers (FID #4)
-------------------------------------------

struct sbiret sbi_debug_enable_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Enable a set of debug triggers specified by `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

To enable a debug trigger, SBI implementation MUST restore the
`vs`, `vu`, `s`, and `u` bits of the mapped HW debug trigger
from their saved copy in `trig_state`.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger enabled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.

Function: Disable a set of triggers (FID #5)
--------------------------------------------

struct sbiret sbi_debug_disable_triggers(unsigned long trig_idx_base,
unsigned long trig_idx_mask)

Disable a set of debug triggers specified by `trig_idx_base` and
`trig_idx_mask` parameters on the calling HART.

To disable a debug trigger, SBI implementation MUST clear the `vs`,
`vu`, `s`, and `u` bits of the mapped HW debug trigger.

The possible error codes returned in `sbiret.error` are below.

Errors:
SBI_SUCCESS - Trigger disabled successfully.
SBI_ERR_INVALID_PARAM - One of the `trig_idx` in the specified set
of debug triggers is either:
1) Greater than the total number of triggers.
2) Represents a debug trigger that is not
mapped to any HW debug trigger.


Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Aaron Durbin
 



On Mon, Jul 11, 2022 at 7:54 PM Greg Favor <gfavor@...> wrote:
On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:
On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification. 

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.  Whereas in discovery structures one would choose at least somewhat descriptive intuitive names for options and parameters, and would use booleans, integers, enums, etc. - as appropriate - to specify values for the options and parameters.  The latter would be clean and clear and readily captured by a schema.

My point is that the information, regardless of format, needs to be conveyed in some manner to the OS. There's no getting around that aspect. We need to identify 1. all the things the OS needs and 2. how to convey that information for consumption. We're currently talking about #1 and whether a name or whatever is applied to a construct that construct still needs to be properly conveyed. The Profile proposal in its current form is providing names to some of those constructs. Whether that continues and we embrace it going forward is now up for discussion it seems, but that discussion doesn't negate the fact that we have to enumerate many things to the OS for it to make correct decisions. 


Instead using a very large number of terse extension-style names that cover the combinatorial namespace of all allowed K-V pairs, let alone needing to define a universal naming scheme to follow across the entire architecture now and into the future, seems to result in less comprehensible discovery info and will push out even farther into the future having all this worked out.  Whereas developing simple conventions for naming of options and parameters, and for specifying allowed values, and then having each TG that is developing an extension define the specific names (and allowed values) for the options and parameters of the extension, is relatively straightforward and scalable.  This is part of what tech-config was trying to enable.  (For past extensions, there of course is remedial work to be done, but the idea remains.)

I don't think the having a name for something or not reduces comprehensibility of discovery info. It all needs to be enumerated in one form or another. The question is how to get to a consistent way to describing these constructs across the ecosystem. The divide and conquer approach will work, but I'm not sure we'll get consistent names. If that's not a goal, so be it. Either way, we need to go and backfill things that don't have names/identifiers.
 

In short we need to divide-and-conquer the overall issue and not pile everything into one big ball of yarn.  And let's focus on supporting UD/DT/ACPI discovery methods.  Practically speaking, let's leave the relatively very limited naming in profiles of line item mandates, to the profiles.  Let these be two different and only superficially related problems.   (Ok, I'll step off my soapbox now.)

In order to focus on the discovery methods we need to have the set of things needed by each level the software to be enumerated and provide a way to name/identify those pieces. As you noted above, there may be different types needed, but that requirement falls out from the data gatherig step. However, we'll still need to figure out how to encode all this information anyway for DT and ACPI.
 

Greg







Re: [RISC-V] [tech-aia] [RISC-V][tech-os-a-see] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Philipp Tomsich <philipp.tomsich@...>
 

Allen,

Rereading your comment, I realised that something was off (as I didn't
have a line 244) — looks like I missed the additional tabs on the
inline preview of the sheet in the mail program.
Thanks for point that out!

Philipp.

On Tue, 12 Jul 2022 at 02:09, Allen Baum <allen.baum@...> wrote:

I'm not sure what you're referring to
Line 244 list Zihintpause
Lines 180-188 list Zvlsseg, Zvamo, Zvediv, Zvqmac, Zve32x, Zve32f, Zve64x, Zve64f, Zve64d
Lines 138-147 list Zba, Zbb, Zbc, Zbe, Zbf, Zbm, Zbp, Zbr, Zbs, Zbt (many of which are not yet ratified)

On Mon, Jul 11, 2022 at 1:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:

Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

On Mon, 11 Jul 2022 at 22:16, Allen Baum <allen.baum@...> wrote:

FYI: here is a rough initial draft of the architectural options that I've been able to dig up.
I know that this is very, very likely to be incomplete.

This is written from the perspective of how to make our reference model model the behavior of a device under test.
That's a very different use case than what is needed for ACPI, so I have no clue which of these options require a
parameter to be supplied (as opposed to defining the parameter) and which are don't cares.

Most of this was derived from the Imperas simulator options.

Sail will eventually have CSR definitions that will be supplied from a YAML formatted riscv-config file that describes the properties of a CSR
(e.g. which are implemented, which bits are RW, what the RO values are, what the ranges of legal values are for RW fields, and what the illegal->legal mapping function is for WARL fields). Entries marked "use CSR definitions" means that don't need to be given names, but can be derived from that YAML description (though the profiles names are restrictions on top of the architecturally allowed behaviors for a particular profile)

The unified discovery spec will be encoding some of these as well, and perhaps some other things which could be derived from this.


Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor
 

On Mon, Jul 11, 2022 at 11:28 AM Aaron Durbin <adurbin@...> wrote:
On Mon, Jul 11, 2022 at 12:19 PM Greg Favor <gfavor@...> wrote:
What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired).  Whereas Profiles have a more limited goal of having extension-like names for specific K-V pairs.  The latter names are different animals than the former - not only semantically but also in being short not-so-self-descriptive acronyms (not exactly what you want for K names).

In short, keep these two areas uncoupled from each other and let each struggle down its own path without getting further delayed by each other.

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a different way to identify the construct we have 2 different ways of identification. 

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.  Whereas in discovery structures one would choose at least somewhat descriptive intuitive names for options and parameters, and would use booleans, integers, enums, etc. - as appropriate - to specify values for the options and parameters.  The latter would be clean and clear and readily captured by a schema.

Instead using a very large number of terse extension-style names that cover the combinatorial namespace of all allowed K-V pairs, let alone needing to define a universal naming scheme to follow across the entire architecture now and into the future, seems to result in less comprehensible discovery info and will push out even farther into the future having all this worked out.  Whereas developing simple conventions for naming of options and parameters, and for specifying allowed values, and then having each TG that is developing an extension define the specific names (and allowed values) for the options and parameters of the extension, is relatively straightforward and scalable.  This is part of what tech-config was trying to enable.  (For past extensions, there of course is remedial work to be done, but the idea remains.)

In short we need to divide-and-conquer the overall issue and not pile everything into one big ball of yarn.  And let's focus on supporting UD/DT/ACPI discovery methods.  Practically speaking, let's leave the relatively very limited naming in profiles of line item mandates, to the profiles.  Let these be two different and only superficially related problems.   (Ok, I'll step off my soapbox now.)

Greg







Re: [RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Greg Favor
 

On Mon, Jul 11, 2022 at 2:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking.
Given that this does not provide a significant benefit, it seems safer to stick with the canonical form listing the base and individual extensions.

What is the expected benefit from duplicating this information?

This was a point I tried to make in another thread about tech-config and profiles.  Support for a profile implies support for all the extensions mandated by the profile (but still leaves unspecified the support for further extensions).

So the question - that should be answered by the direct software user community of tech-config discovery structures - is whether the rest of a tech-config structure must only specify supported extensions not mandated by a profile, or must it also specify (redundantly) all the supported individual extensions, or is any degree of redundancy from zero to full allowed?

For example, having full redundancy would allow someone to simply check for presence of a specific extension of interest - without having to also check profile presence bits and understand what each of them implies.  Conversely, does someone feel that any redundancy creates confusion or complications for software using tech-config structures?

The rest of us can raise questions, but the direct users of tech-config are the best ones to determine the right answer.

Greg


Re: [RISC-V] [tech-aia] [RISC-V][tech-os-a-see] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Allen Baum
 

Ah, never mind. My version of the spreadsheet opens to sheet3, and that's what has the complete list. The other sheets were used to develop this one.
I will rename the sheet and put it in the front. and also move unratified extensions to another sheet

On Mon, Jul 11, 2022 at 5:09 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
I'm not sure what you're referring to
Line 244 list Zihintpause
Lines 180-188 list Zvlsseg, Zvamo, ZvedivZvqmacZve32xZve32fZve64xZve64fZve64d
Lines 138-147 list Zba, ZbbZbcZbeZbfZbmZbpZbrZbsZbt (many of which are not yet ratified)

On Mon, Jul 11, 2022 at 1:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

On Mon, 11 Jul 2022 at 22:16, Allen Baum <allen.baum@...> wrote:
>
> FYI: here is a rough initial draft of the architectural options that I've been able to dig up.
> I know that this is very, very likely to be incomplete.
>
> This is written from the perspective of how to make our reference model model the behavior of a device under test.
> That's a very different use case than what is needed for ACPI,  so I have no clue which of these options require a
> parameter to be supplied (as opposed to defining the parameter) and which are don't cares.
>
> Most of this was derived from the Imperas simulator options.
>
> Sail will eventually have CSR definitions that will be supplied from a YAML formatted riscv-config file that describes the properties of a CSR
> (e.g. which are implemented, which bits are RW, what the RO values are, what the ranges of legal values are for RW fields, and what the illegal->legal mapping function is for WARL fields). Entries marked "use CSR definitions" means that don't need to be given names, but can be derived from that YAML description (though the profiles names are restrictions on top of the architecturally allowed behaviors for a particular profile)
>
> The unified discovery spec will be encoding some of these as well, and perhaps some other things which could be derived from this.


Re: [RISC-V] [tech-aia] [RISC-V][tech-os-a-see] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Allen Baum
 

They are marked in the spreadsheet as "Ignored in v1.0", for what it's worth, 
but I could make it more obvious (or better, move them to a separate sheet-- done)

On Mon, Jul 11, 2022 at 5:53 PM Greg Favor <gfavor@...> wrote:
On Mon, Jul 11, 2022, 5:09 PM Allen Baum <allen.baum@...> wrote:
I'm not sure what you're referring to
Line 244 list Zihintpause
Lines 180-188 list Zvlsseg, Zvamo, ZvedivZvqmacZve32xZve32fZve64xZve64fZve64d
Lines 138-147 list Zba, ZbbZbcZbeZbfZbmZbpZbrZbsZbt (many of which are not yet ratified)

Alan,

Given the recent troubles with people having taken extensions in the priv/unpriv spec documents as being official even though they are listed as unratified, I would suggest not listing extensions that have no active plan to be ratified nor any group actively or planning to actively pursue ratification - in particular the unratified bitmanip extensions.

Similarly, no dev effort should be spent on these possibly never to be ratified extension proposals.

Better to stick to ratified extensions, or clearly mark extensions that are working towards being ratified over the coming year.

Greg 



On Mon, Jul 11, 2022 at 1:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

On Mon, 11 Jul 2022 at 22:16, Allen Baum <allen.baum@...> wrote:
>
> FYI: here is a rough initial draft of the architectural options that I've been able to dig up.
> I know that this is very, very likely to be incomplete.
>
> This is written from the perspective of how to make our reference model model the behavior of a device under test.
> That's a very different use case than what is needed for ACPI,  so I have no clue which of these options require a
> parameter to be supplied (as opposed to defining the parameter) and which are don't cares.
>
> Most of this was derived from the Imperas simulator options.
>
> Sail will eventually have CSR definitions that will be supplied from a YAML formatted riscv-config file that describes the properties of a CSR
> (e.g. which are implemented, which bits are RW, what the RO values are, what the ranges of legal values are for RW fields, and what the illegal->legal mapping function is for WARL fields). Entries marked "use CSR definitions" means that don't need to be given names, but can be derived from that YAML description (though the profiles names are restrictions on top of the architecturally allowed behaviors for a particular profile)
>
> The unified discovery spec will be encoding some of these as well, and perhaps some other things which could be derived from this.


Re: [RISC-V] [tech-aia] [RISC-V][tech-os-a-see] [RISC-V] [tech-unixplatformspec] Review request for ACPI ECRs

Greg Favor
 

On Mon, Jul 11, 2022, 5:09 PM Allen Baum <allen.baum@...> wrote:
I'm not sure what you're referring to
Line 244 list Zihintpause
Lines 180-188 list Zvlsseg, Zvamo, ZvedivZvqmacZve32xZve32fZve64xZve64fZve64d
Lines 138-147 list Zba, ZbbZbcZbeZbfZbmZbpZbrZbsZbt (many of which are not yet ratified)

Alan,

Given the recent troubles with people having taken extensions in the priv/unpriv spec documents as being official even though they are listed as unratified, I would suggest not listing extensions that have no active plan to be ratified nor any group actively or planning to actively pursue ratification - in particular the unratified bitmanip extensions.

Similarly, no dev effort should be spent on these possibly never to be ratified extension proposals.

Better to stick to ratified extensions, or clearly mark extensions that are working towards being ratified over the coming year.

Greg 



On Mon, Jul 11, 2022 at 1:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:
Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

On Mon, 11 Jul 2022 at 22:16, Allen Baum <allen.baum@...> wrote:
>
> FYI: here is a rough initial draft of the architectural options that I've been able to dig up.
> I know that this is very, very likely to be incomplete.
>
> This is written from the perspective of how to make our reference model model the behavior of a device under test.
> That's a very different use case than what is needed for ACPI,  so I have no clue which of these options require a
> parameter to be supplied (as opposed to defining the parameter) and which are don't cares.
>
> Most of this was derived from the Imperas simulator options.
>
> Sail will eventually have CSR definitions that will be supplied from a YAML formatted riscv-config file that describes the properties of a CSR
> (e.g. which are implemented, which bits are RW, what the RO values are, what the ranges of legal values are for RW fields, and what the illegal->legal mapping function is for WARL fields). Entries marked "use CSR definitions" means that don't need to be given names, but can be derived from that YAML description (though the profiles names are restrictions on top of the architecturally allowed behaviors for a particular profile)
>
> The unified discovery spec will be encoding some of these as well, and perhaps some other things which could be derived from this.

1 - 20 of 1818