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

In case the meeting details are not reflecting in the invite, here is
the info:

Meeting link: https://zoom.us/j/7237830759
Passcode: 741796
Join link: https://zoom.us/j/7237830759?pwd=bGE2QkMwNm1xclF4SDI1cll0Mk1LQT09

Thanks
Sunil

On Mon, Jun 27, 2022 at 06:58:15PM +0530, Anup Patel wrote:

The rationale is that for M-mode the memory type is always defined by
PMA(s) so if supervisor-mode software overrides memory type using
Svpbmt then M-mode firmware will not see same contents as the
supervisor-mode software.

I get the intent now. But we may not want to prohibit that.

We may want to document that the SBI will access this memory using
the PMA attribute.

If the supervisor has accessed this same location using different cachability attribute than the 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 Svpbmt specification to prevent the loss of coherence and memory ordering.

This does not place a restriction but warns against the issue and
points to the right sequence if there is a legitimate reason to do it.

This should not be specific to this function but applicable to any
function that the SBI defines with a memory operand and so could be
stated more generally in the SBI specification.

regards
ved

On Mon, Jun 27, 2022 at 6:16 PM Ved Shanbhogue <ved@...> wrote:

On Mon, Jun 27, 2022 at 05:38:43PM +0530, Anup Patel wrote:

Also, a system might be partitioned into domains so a supervisor software
running in a particular domain can only pass addresses accessible in that
domain.

So domain is a new term which is not presently defined in the privileged
specification or in the SBI specification.

The term "domain" is not used in the proposal since it is OpenSBI specific.
My comment was mainly for Heinrich since he is already aware of OpenSBI
domains.

In general, other M-mode firmwares might also implement some kind of
system level partitioning.

I think I get what you may be stating here i.e., M-mode may configure/
reconfigure PMPs to restrict the physical addresses that are accessible to
the supervisor-mode. Perhaps a future Smpu extension may add to this mix.

To avoid inventing a new term, we could reword #1 to state that the physical
address must be accessible, as determined by the PMP and/or PMA rules, to the
supervisor mode software invoking this SBI function.

To further restrict this perhaps say "accessible to read"? As we may not want
execute-only to be allowed by this extension.

I mostly agree with your wording. Considering hypervisors and future memory
protection ISA extensions, let's avoid using terms PMP.

For #1, we can say:
The SBI implementation MUST check that the supervisor-mode software
is allowed to read the specified physical address range on the calling HART.

For OpenSBI, we have domain regions so OpenSBI will check the address
against regions of the domain assigned to calling HART.

Since "domain" is a concept that is not defined by either the privilege
specification or the SBI specification we may want to avoid using that
term (or add a definition).

The term "domain" was only in the context of OpenSBI. We should not use
this term in the SBI specification.

This is more a requirement on the supervisor-mode software because
we might have a system with Svpbmt so on such system supervisor-mode
should not pass an address which is mapped as non-cacheable in the
page table.

This is confusing since the description states that the parameter is a
physical address but the later comment states its a virtual address
and the memory type override using page-based memory type provided by
the virtual memory system is allowed. Could we clarify if its a physical
address - in which case only the coherence and cachability PMA should
provide the memory type - or a virtual address in which case page-based
memory type override is possible.

Further, a brief explanation about why cachability matters for this
extension would be useful. Is this trying to imply some kind of early
boot execution where caches may be placed in a special mode that allows
operation when main memory is not available.

I agree the #2 requirement is not clear enough.

For #2, we can say:
The supervisor-mode software MUST not override the memory type of
specified physical address range using page-based memory types.

The rationale is that for M-mode the memory type is always defined by
PMA(s) so if supervisor-mode software overrides memory type using
Svpbmt then M-mode firmware will not see same contents as the
supervisor-mode software.

Regards,
Anup

On Mon, Jun 27, 2022 at 05:38:43PM +0530, Anup Patel wrote:

Also, a system might be partitioned into domains so a supervisor software
running in a particular domain can only pass addresses accessible in that
domain.

So domain is a new term which is not presently defined in the privileged specification or in the SBI specification.

I think I get what you may be stating here i.e., M-mode may configure/
reconfigure PMPs to restrict the physical addresses that are accessible to the supervisor-mode. Perhaps a future Smpu extension may add to this mix.

To avoid inventing a new term, we could reword #1 to state that the physical address must be accessible, as determined by the PMP and/or PMA rules, to the
supervisor mode software invoking this SBI function.

To further restrict this perhaps say "accessible to read"? As we may not want execute-only to be allowed by this extension.

For OpenSBI, we have domain regions so OpenSBI will check the address
against regions of the domain assigned to calling HART.

Since "domain" is a concept that is not defined by either the privilege
specification or the SBI specification we may want to avoid using that
term (or add a definition).

This is more a requirement on the supervisor-mode software because
we might have a system with Svpbmt so on such system supervisor-mode
should not pass an address which is mapped as non-cacheable in the
page table.

This is confusing since the description states that the parameter is a
physical address but the later comment states its a virtual address
and the memory type override using page-based memory type provided by
the virtual memory system is allowed. Could we clarify if its a physical
address - in which case only the coherence and cachability PMA should provide the memory type - or a virtual address in which case page-based memory type override is possible.

Further, a brief explanation about why cachability matters for this extension would be useful. Is this trying to imply some kind of early
boot execution where caches may be placed in a special mode that allows
operation when main memory is not available.

regards
ved

On 6/27/22 14:08, Anup Patel wrote:

On Mon, Jun 27, 2022 at 4:45 PM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 6/27/22 10:46, 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 short, the SBI debug console extension defines a standard way
for boot-time early prints in supervisor-mode software.

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

Why should only S-mode and not HS-mode be allowed? I think the modes
that are allowed to access this extension should be enumerated more clearly.

The term "supervisor-mode" over here means:
* HS-mode or VS-mode on systems with H-extension
* S-mode on systems without H-extension
(Please see the introduction chapter of SBI specification)
In fact, both HS-mode and VS-mode are actually supervisor-mode with
different capabilities.

How are systems treated that only have M-mode and U-mode?

For systems with only M-mode and U-mode, there is no supervisor-mode
hence there is no SBI on such systems. These are embedded-class
systems which usually run some kind of RTOS.

boot-time issues in supervisor-mode software.

This extension replaces legacy console putchar (EID #0x01) extension
and it is better in following ways:
1) It follows the new calling convention defined for SBI v1.0
(or higher).
2) It allows supervisor software to print multiple characters
in a single SBI call.

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_div_by_4,
unsigned long num_chars)

Print the string specified by the `addr_div_by_4` and `num_chars`
parameters on the debug console. The `addr_div_by_4` parameter is
the physical base address of the string right shifted by 2 whereas
the `num_chars` parameter is the number of characters (or bytes) in
the string.

The memory pointed the `addr_div_by_4` and `num_chars` parameters
must be:
1) Accessible to supervisor-mode
2) Cacheable and writable memory

Accessibility by supervisor-mode is required due to security
considerations: You should not be able to print out M-mode's secrets via
S-mode software. This should be clearly stated.

The point#1 tries to say this.
Also, a system might be partitioned into domains so a supervisor software
running in a particular domain can only pass addresses accessible in that
domain.

MUST an SBI implementation check this feature? Probably yes. How shall
it be checked?

It's up to the SBI implementation how to check this feature.

As this is a security feature we should require:

The SBI MUST check that the full memory range is read-accessible by the caller.

For OpenSBI, we have domain regions so OpenSBI will check the address
against regions of the domain assigned to calling HART.
For KVM, the user-space tool (QEMU/KVMTOO) knows the guest physical
address range of Guest RAM which can be used to validate the address.

The SBI is not meant to change the string and therefore needs no write
access. There is no reason to require that the memory should be
writable. The string could reside in NOR flash.

Caching may speed up the SBI code. But why should we require this
specific memory region being cached?

This is more a requirement on the supervisor-mode software because
we might have a system with Svpbmt so on such system supervisor-mode
should not pass an address which is mapped as non-cacheable in the
page table.
We can certainly re-word this requirement to:
"Cacheable and readable memory"

Here too we should make it clear if the SBI MUST or MAY check the property. I guess MAY is enough.

Best regards

Heinrich

One of the replies to your v1 patch requested to have the same
capabilities as putchar(): just pass a single character in a register.
Should a second FID be added?

It's pretty easy to print a single character using the proposed puts()
call.
For assembly source perspective, this will be just one extra instruction.
Regards,
Anup

Best regards

Heinrich

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_div_by_4`
and `num_chars` parameters is either not
accessible to supervisor-mode or does not
point to cacheable and writable memory.
SBI_ERR_FAILED - Failed to print characters due to
I/O errors.

On Mon, Jun 27, 2022 at 4:45 PM Heinrich Schuchardt <xypron.glpk@...> wrote:

On 6/27/22 10:46, 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 short, the SBI debug console extension defines a standard way
for boot-time early prints in supervisor-mode software.

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

Why should only S-mode and not HS-mode be allowed? I think the modes
that are allowed to access this extension should be enumerated more clearly.

The term "supervisor-mode" over here means:
* HS-mode or VS-mode on systems with H-extension
* S-mode on systems without H-extension
(Please see the introduction chapter of SBI specification)

In fact, both HS-mode and VS-mode are actually supervisor-mode with
different capabilities.

How are systems treated that only have M-mode and U-mode?

For systems with only M-mode and U-mode, there is no supervisor-mode
hence there is no SBI on such systems. These are embedded-class
systems which usually run some kind of RTOS.

boot-time issues in supervisor-mode software.

This extension replaces legacy console putchar (EID #0x01) extension
and it is better in following ways:
1) It follows the new calling convention defined for SBI v1.0
(or higher).
2) It allows supervisor software to print multiple characters
in a single SBI call.

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_div_by_4,
unsigned long num_chars)

Print the string specified by the `addr_div_by_4` and `num_chars`
parameters on the debug console. The `addr_div_by_4` parameter is
the physical base address of the string right shifted by 2 whereas
the `num_chars` parameter is the number of characters (or bytes) in
the string.

The memory pointed the `addr_div_by_4` and `num_chars` parameters
must be:
1) Accessible to supervisor-mode
2) Cacheable and writable memory

Accessibility by supervisor-mode is required due to security
considerations: You should not be able to print out M-mode's secrets via
S-mode software. This should be clearly stated.

The point#1 tries to say this.

Also, a system might be partitioned into domains so a supervisor software
running in a particular domain can only pass addresses accessible in that
domain.

MUST an SBI implementation check this feature? Probably yes. How shall
it be checked?

It's up to the SBI implementation how to check this feature.

For OpenSBI, we have domain regions so OpenSBI will check the address
against regions of the domain assigned to calling HART.

For KVM, the user-space tool (QEMU/KVMTOO) knows the guest physical
address range of Guest RAM which can be used to validate the address.

The SBI is not meant to change the string and therefore needs no write
access. There is no reason to require that the memory should be
writable. The string could reside in NOR flash.

Caching may speed up the SBI code. But why should we require this
specific memory region being cached?

This is more a requirement on the supervisor-mode software because
we might have a system with Svpbmt so on such system supervisor-mode
should not pass an address which is mapped as non-cacheable in the
page table.

We can certainly re-word this requirement to:
"Cacheable and readable memory"

One of the replies to your v1 patch requested to have the same
capabilities as putchar(): just pass a single character in a register.
Should a second FID be added?

It's pretty easy to print a single character using the proposed puts()
call.

For assembly source perspective, this will be just one extra instruction.

Regards,
Anup

Best regards

Heinrich

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_div_by_4`
and `num_chars` parameters is either not
accessible to supervisor-mode or does not
point to cacheable and writable memory.
SBI_ERR_FAILED - Failed to print characters due to
I/O errors.

On 6/27/22 10:46, 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 short, the SBI debug console extension defines a standard way
for boot-time early prints in supervisor-mode software.

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

Why should only S-mode and not HS-mode be allowed? I think the modes
that are allowed to access this extension should be enumerated more clearly.

How are systems treated that only have M-mode and U-mode?

boot-time issues in supervisor-mode software.

This extension replaces legacy console putchar (EID #0x01) extension
and it is better in following ways:
1) It follows the new calling convention defined for SBI v1.0
(or higher).
2) It allows supervisor software to print multiple characters
in a single SBI call.

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_div_by_4,
unsigned long num_chars)

Print the string specified by the `addr_div_by_4` and `num_chars`
parameters on the debug console. The `addr_div_by_4` parameter is
the physical base address of the string right shifted by 2 whereas
the `num_chars` parameter is the number of characters (or bytes) in
the string.

The memory pointed the `addr_div_by_4` and `num_chars` parameters
must be:
1) Accessible to supervisor-mode
2) Cacheable and writable memory

Accessibility by supervisor-mode is required due to security
considerations: You should not be able to print out M-mode's secrets via
S-mode software. This should be clearly stated.

MUST an SBI implementation check this feature? Probably yes. How shall
it be checked?

The SBI is not meant to change the string and therefore needs no write
access. There is no reason to require that the memory should be
writable. The string could reside in NOR flash.

Caching may speed up the SBI code. But why should we require this
specific memory region being cached?

One of the replies to your v1 patch requested to have the same
capabilities as putchar(): just pass a single character in a register.
Should a second FID be added?

Best regards

Heinrich

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_div_by_4`
and `num_chars` parameters is either not
accessible to supervisor-mode or does not
point to cacheable and writable memory.
SBI_ERR_FAILED - Failed to print characters due to
I/O errors.

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 short, the SBI debug console extension defines a standard way
for boot-time early prints in supervisor-mode software.

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 legacy console putchar (EID #0x01) extension
and it is better in following ways:
1) It follows the new calling convention defined for SBI v1.0
(or higher).
2) It allows supervisor software to print multiple characters
in a single SBI call.

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_div_by_4,
unsigned long num_chars)

Print the string specified by the `addr_div_by_4` and `num_chars`
parameters on the debug console. The `addr_div_by_4` parameter is
the physical base address of the string right shifted by 2 whereas
the `num_chars` parameter is the number of characters (or bytes) in
the string.

The memory pointed the `addr_div_by_4` and `num_chars` parameters
must be:
1) Accessible to supervisor-mode
2) Cacheable and writable memory

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_div_by_4`
and `num_chars` parameters is either not
accessible to supervisor-mode or does not
point to cacheable and writable memory.
SBI_ERR_FAILED - Failed to print characters due to
I/O errors.

On Fri, Jun 24, 2022 at 8:31 AM Sunil V L <sunilvl@...> wrote:

On Thu, Jun 23, 2022 at 11:30:28PM +0400, Furquan Shaikh wrote:

Hello Sunil,

Thanks for sending out these ECRs. After looking at these documents,
we have a lot of comments/questions, but I think it might be
productive to walk through the assumptions and approach for defining
these structures over a meeting with interested RISC-V members. What
do you think?

Hi Furquan,

Yes, let's do that. I will setup a meeting on Monday 27th 2022. We can
continue the discussion later if we can not finish in an hour.

Sounds good. Thanks, Sunil!

- Furquan

Thanks!
Sunil

Thanks,
Furquan

On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> 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

On Thu, Jun 23, 2022 at 11:30:28PM +0400, Furquan Shaikh wrote:

Hello Sunil,

Thanks for sending out these ECRs. After looking at these documents,
we have a lot of comments/questions, but I think it might be
productive to walk through the assumptions and approach for defining
these structures over a meeting with interested RISC-V members. What
do you think?

Hi Furquan,

Yes, let's do that. I will setup a meeting on Monday 27th 2022. We can
continue the discussion later if we can not finish in an hour.

Thanks!
Sunil

Thanks,
Furquan

On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> 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

Hello Sunil,

Thanks for sending out these ECRs. After looking at these documents,
we have a lot of comments/questions, but I think it might be
productive to walk through the assumptions and approach for defining
these structures over a meeting with interested RISC-V members. What
do you think?

Thanks,
Furquan

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

Although the deadline has past, it was mentioned at the Software HC meeting
last week that there are no candidates for the vice-chair position, so I
would like to nominate myself.

I have been involved with RISC-V since 2013, contributing to the RISC-V
port of various software projects and working on Bluespec hardware and
software products centered on RISC-V. My past experience includes embedded
system software and hardware development and processor design.

I would like to help facilitate making the OS-A SEE (or whatever it gets
called) specification something practical and useful as well as seeing it
through to ratification in a timely manner.

Thank you for the consideration.

// darius

On Mon, Jun 6, 2022 at 8:42 AM Stephano Cetola <stephano@...> wrote:

More than this, the specification cannot go to Freeze (public review)
until any SBI changes are in place.

One thing we might want to consider is having an "SBI approval"
process. That would allow SBI changes to be "upstreamed but not
released", and allow specifications to go to Freeze & Ratification

Do you mean SBI spec changes are merged in the spec but the SBI spec
is not frozen
by itself ?

while they wait for the SBI changes to be released in the next version
of SBI.

Release of the SBI specification - ratified version or frozen is fine ?
As long as dependent specs can go into public review once SBI spec is
frozen, that should be fine too.
As SBI spec is a software spec, a PoC implementation is the most
critical step here.

This is no different than the upstreaming of things like GCC today. We
could make these changes to the process without changing the policy.
(no vote needed)

Cheers,
Stephano

On Thu, Jun 2, 2022 at 8:06 AM mark <markhimelstein@...> wrote:

Just remember that something that depends on an SBI change can't get ratified until the SBI change is ratified.

If there is a roll up, there still needs to a TG governing it or it needs to be a fast track with the committee governing it and there needs to be a rat plan.

Mark

On Thu, Jun 2, 2022 at 7:38 AM Anup Patel <apatel@...> wrote:

On Thu, Jun 2, 2022 at 7:36 PM mark <markhimelstein@...> wrote:

we have seen a number of SBI changes proposed (debug console, ap tee, ...).

will there be one big rev ala priv 1.12, small fast tracks , something else?

I also suggest that this either needs to be run out of the priv sw HC or convene a new TG. Can we conduct this conversation there (and create the appropriate group or committee mail aliases).

My understanding is that different TGs or SIGs will propose their own
SBI extensions. Once a set of changes for next SBI spec release are
finalized, the SBI TG can collect all new SBI extensions and prepare a
draft of the next SBI spec. It will be the responsibility of SBI TG to
complete the ratification process.

Is this understanding correct ?

Regards,
Anup

Thanks
Mark

--------
sent from a mobile device. please forgive any typos.

More than this, the specification cannot go to Freeze (public review)
until any SBI changes are in place.

One thing we might want to consider is having an "SBI approval"
process. That would allow SBI changes to be "upstreamed but not
released", and allow specifications to go to Freeze & Ratification
while they wait for the SBI changes to be released in the next version
of SBI.

This is no different than the upstreaming of things like GCC today. We
could make these changes to the process without changing the policy.
(no vote needed)

Cheers,
Stephano