Date   

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

Sunil V L
 

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 Fri, Jun 24, 2022 at 03:42:14PM +0400, Furquan Shaikh wrote:
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








Re: SBI Debug Console Extension Proposal (Draft v2)

Ved Shanbhogue
 

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


Re: SBI Debug Console Extension Proposal (Draft v2)

Anup Patel
 

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


Re: SBI Debug Console Extension Proposal (Draft v2)

Ved Shanbhogue
 

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


Re: SBI Debug Console Extension Proposal (Draft v2)

Heinrich Schuchardt
 

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.


Re: SBI Debug Console Extension Proposal (Draft v2)

Anup Patel
 

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.


Re: SBI Debug Console Extension Proposal (Draft v2)

Heinrich Schuchardt
 

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.


SBI Debug Console Extension Proposal (Draft v2)

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 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.


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

Furquan Shaikh
 

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








Invitation: Ad-hoc ACPI ECR Review meeting @ Mon Jun 27, 2022 9:30pm - 10:30pm (IST) (tech-unixplatformspec@lists.riscv.org)

Sunil V L
 

You have been invited to the following event.

Ad-hoc ACPI ECR Review meeting

When
Mon Jun 27, 2022 9:30pm – 10:30pm India Standard Time - Kolkata
Joining info
Join with Google Meet
Join by phone
(US) +1 567-443-0759 (PIN: 987181039)
Calendar
tech-unixplatformspec@...
Who
sunilvl@... - organizer
tech-unixplatformspec@...
tech-os-a-see@...
Atish Kumar Patra
furquan@...
apatel@...
tech.meetings@...
Hi All,

This is an ad-hoc meeting to go over the ACPI ECR proposals. Will update the zoom link before the meeting.

Thanks
Sunil

Going (tech-unixplatformspec@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tech-unixplatformspec@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


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

Sunil V L
 

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








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

Furquan Shaikh
 

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

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





Review request for ACPI ECRs

Sunil V L
 

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-os-a-see] Call for Candidates - OS-A SEE TG

Darius Rad
 

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 Thu, May 12, 2022 at 12:58:25PM -0600, Aaron Durbin wrote:
All,

As per the policy governing chairs and vice chairs, we are holding a call
for candidates for the positions of CHAIR and VICE-CHAIR for the OS-A SEE
TG. To nominate yourself or another member of the community, please respond
to this thread with a short biography of the candidate (less than 250
words) as well as a statement of intent (less than 250 words).

If both Chair and Vice-Chair are available, candidates may nominate for one
or both roles.

A diversity of ideas and contributions, one that originates from a diverse
community, from all walks of life, cultures, countries, and skin colors—is
vital for building sustainable and healthy open source communities.
Individuals from diverse backgrounds inject new and innovative ideas to
advance an inclusive and welcoming ecosystem for all. RISC-V is committed
to building diverse and inclusive communities.

This call for candidates will be open for 2 weeks, ending on May 26, 2022
(inclusive).

If you have any questions regarding this process please contact
help@....

The current approved charter by the Priv SW HC (nee Software HC) can be
found here <https://github.com/riscv-admin/os-a-see/blob/main/CHARTER.md>.

Kind regard,
Aaron Durbin





Re: SBI changes

atishp@...
 

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.







Re: SBI changes

Stephano Cetola
 

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

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.




Re: SBI Debug Console Extension Proposal (Draft v1)

Darius Rad
 

On Wed, Jun 01, 2022 at 09:47:32PM +0530, Anup Patel wrote:

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 is based on a shared memory area between SBI implementation
and supervisor-mode software so multiple characters can be
printed using a single SBI call.

The supervisor-mode software must set the shared memory area before
printing characters on the debug console. Also, all HARTs share the
same shared memory area so only one HART needs to set it at boot-time.
It seems to me that the rationale and summary of the extension is
insufficient, and non-normative commentary is lacking. The ensuing mailing
list discussion suggests that there are additional requirements and
assumptions that influenced the design of the interface, but are not
mentioned here. It is important to document such information, in order to
have a constructive discussion now, and also to preserve such information
for readers in the future who may not have the benefit of reading the
mailing list discussions.

// darius


Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)

Schwarz, Konrad <konrad.schwarz@...>
 

-----Original Message-----
From: Alistair Francis <Alistair.Francis@...>
Sent: Friday, June 3, 2022 10:47
Consider the case where we have more VMs than physical UARTs -- this
will actually be the norm in most deployments.
In this case you should use virtIO or some other more powerful
interface


(To counter the argument that the hypervisor can provide virtual
UARTs
for its guests, note that a dedicated para-virtualized interface is
much more
efficient than trapping individual memory accesses to simulated HW
registers).
Agreed, but tha seems up to the Hypervisor to implement an effient
virtual UART implementation. For example the Xen HYPERVISOR_console_io
that Stefano mentioned earlier. Plus then we can leverage existing
implementations insted of inveting a another virtual serial device.
But this makes it incumbent on each hypervisor to provide such an
interface, and requires each OS to provide drivers for each
hypervisor it knows about. You then have an N:M situation,
which is bad for the RISC-V platform.

By making the interface a bit richer, as discussed in my earlier
proposal,
a hypervisor can cover a much larger set of use cases.
Which we also then need to support in M-mode firmware. The more complex
the firmware becomes the more exposed it is.
The same argument applies to hypervisors. What fundamental difference
between M-mode and HS-mode software is there that makes the risk
so much different?

An implementation wishing to minimize its responsibilities can
always return run-time errors for functionality it does not
wish to support.

--
Konrad


Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)

Alistair Francis
 

On Fri, 2022-06-03 at 07:49 +0000, Schwarz, Konrad wrote:

From:
sig-hypervisors@... <sig-hypervisors@...>
On Behalf Of Anup Patel via
lists.riscv.org
Sent: Friday, June 3, 2022 5:01
We have legacy SBI v0.1 calls where most of them are replaced by
newer SBI v0.2 (or higher) calls. Only the SBI v0.1 putchar() does
not
have a replacement. This putchar() was being used in various cases
for early prints from OSes and bootloaders.

The SBI debug console extension is an attempt to replace the legacy
SBI v0.1 putchar(). The use of shared memory in this proposal is
motivated by the need to allow users to print multiple characters
in
one SBI call.
As I pointed out in an earlier message, the design using a shared
memory block
is a hindrance.  Instead, each call should provide a pointer to the
(virtual)
address of the character buffer.
I agree

With the current design there is no way for the supervisor software to
reclaim the memory once it has shared it with OpenSBI. We can add a
close() call, but it seems simpler and safer to instead just pass an
address and size to print.


The legacy SBI v0.1 also had a getchar() call which is deprecated
and
does not need any newer SBI call replacing it because it is
expected
all platforms (including virtual platforms emulated by hypervisors)
will
have a proper interrupt driver console for supervisor software. The
proposed SBI debug console extension only tries to provide a
solution
for early prints.
Consider the case where we have more VMs than physical UARTs -- this
will actually be the norm in most deployments.
In this case you should use virtIO or some other more powerful
interface


(To counter the argument that the hypervisor can provide virtual
UARTs
for its guests, note that a dedicated para-virtualized interface is
much more
efficient than trapping individual memory accesses to simulated HW
registers).
Agreed, but tha seems up to the Hypervisor to implement an effient
virtual UART implementation. For example the Xen HYPERVISOR_console_io
that Stefano mentioned earlier. Plus then we can leverage existing
implementations insted of inveting a another virtual serial device.


By making the interface a bit richer, as discussed in my earlier
proposal,
a hypervisor can cover a much larger set of use cases.
Which we also then need to support in M-mode firmware. The more complex
the firmware becomes the more exposed it is.

Alistair



--
Konrad





Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)

Schwarz, Konrad <konrad.schwarz@...>
 

From: sig-hypervisors@... <sig-hypervisors@...> On Behalf Of Anup Patel via
lists.riscv.org
Sent: Friday, June 3, 2022 5:01
We have legacy SBI v0.1 calls where most of them are replaced by
newer SBI v0.2 (or higher) calls. Only the SBI v0.1 putchar() does not
have a replacement. This putchar() was being used in various cases
for early prints from OSes and bootloaders.

The SBI debug console extension is an attempt to replace the legacy
SBI v0.1 putchar(). The use of shared memory in this proposal is
motivated by the need to allow users to print multiple characters in
one SBI call.
As I pointed out in an earlier message, the design using a shared memory block
is a hindrance. Instead, each call should provide a pointer to the (virtual)
address of the character buffer.

The legacy SBI v0.1 also had a getchar() call which is deprecated and
does not need any newer SBI call replacing it because it is expected
all platforms (including virtual platforms emulated by hypervisors) will
have a proper interrupt driver console for supervisor software. The
proposed SBI debug console extension only tries to provide a solution
for early prints.
Consider the case where we have more VMs than physical UARTs -- this
will actually be the norm in most deployments.

(To counter the argument that the hypervisor can provide virtual UARTs
for its guests, note that a dedicated para-virtualized interface is much more
efficient than trapping individual memory accesses to simulated HW registers).

By making the interface a bit richer, as discussed in my earlier proposal,
a hypervisor can cover a much larger set of use cases.


--
Konrad

81 - 100 of 1846