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.
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.
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.
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).
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?
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.
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).
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.
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).
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.
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@....
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)
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.
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.
-----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.
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.
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.
On Thu, 2 Jun 2022, Vedvyas Shanbhogue via
lists.riscv.org wrote:
> Of course a console is needed. But I was questioning the need for something much
> more elaborate than a putchar/getchar interface. I understand its needed to port
> the hypervisor but I undersatnd it would be needed for very early parts of the
> hypervisor where it does not even have the ability to master a uart on its own.
Yeah, I think you are right that it is not a must-have feature but a
nice-to-have feature.
Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have found that to be a risky presumption in
certain production environments where boot time matters (especially with frequent standing up of VMs from scratch). So a worthwhile sanity check question would be 1) what percentage of early boot time is spent writing to the console with per-string SBI calls,
and 2) by what order of magnitude does that percentage inflate due to SBI calls for every individual character.
Starting at 1% and inflating to 10%-100% would not be good. Starting at 0.01% and inflating to 0.1-1% is likely acceptable.
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:
Thanks for starting to close this gap.
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.
I miss a discussion of the conflicts that can arise if the configuration of the serial console is changed by the caller.
Do we need an ecall that closes the SBI console to further access?
Usually, the serial port related code in M-mode firmware only uses status and data registers so for most serial ports support the M-mode firmware will adapt to serial port configuration changes.
In fact, this is why we never had a special SBI call for serial port reconfiguration in legacy SBI v0.1 as well.
In case of virtualization, the serial port (or console) is emulated so the special SBI call is not useful for virtualization.
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.
Isn't it M-mode software that has to program the MMU to allow all harts in M-mode and S-mode access to the memory area? What is the S-mode software to do about the memory area prior to calling sbi_debug_console_set_area()?
Actually, it's the S-mode software which is voluntarily giving a portion of its memory to be used as shared memory. The proposal only mandates that whatever memory is selected by S-mode software should be a regular cacheable memory (not IO memory). Also, if Svpbmt is available then S-mode software should only use memory type 0 in the PTEs.
Function: Set Console Area (FID #0) -----------------------------------
struct sbiret sbi_debug_console_set_area(unsigned long addr_div_by_4, unsigned long size)
The console output is needed on the very start of the S-mode software, before setting up anything.
Can we avoid this extra function?
Can we simply assume that the caller of sbi_debug_console_puts() provides a physical address pointer to a memory area that is suitable?
Theoretically, we can avoid the extra function to set shared memory area but it will complicate things in future when we have supervisor software encrypting it's own memory (using special ISA support) because in this case supervisor software will have to unprotect memory every time the sbi_debug_console_puts() is called and protect it again after the call.
Currently this function is just a nop(). It is not needed in this revision of the extension.
The function might be called repeatedly by different threads with different values. How do you want to keep track of all of these different areas?
Memory shared between different security realms will arise in many different scenarios. As this is not console specific it should be in a separate extension. That extension should be defined once we have clarity about how security realms are managed.
I would like to understand more about the security concerns you raised. Can you please elaborate on this ?
I have no security concerns. My thought was that it might be better to manage shared memory in a separate extension for all use cases.
Ahh I see. Sorry I misunderstood your comment. The designated shared memory for debug console is shared across the platforms while STA or PMU use case will have per cpu shared memory.
I agree that all the concerns related to shared memory can be discussed together and all the common constraints can be described at one place.
But defining a separate extension for the shared memory may be problematic as we need to manage the extension dependencies.
Best regards
Heinrich
As you pointed out, there are other possible use cases(e.g STA, PMU) for shared memory between S & M mode or VS & HS mode. It would be good to address these concerns right now instead of discussing those in each individual extension context.
Set the shared memory area specified by `addr_div_by_2` and `size`
%s/addr_div_by_2/addr_div_by_4/
Okay, I will update.
parameters. The `addr_div_by_4` parameter is base address of the
%s/is base/is the base/
Okay, I will update.
shared memory area right shifted by 2 whereas `size` parameter is the size of shared memory area in bytes.
Why shifting the address? I would prefer to keep it simple for the caller. If the alignment is not suitable, return an error.
But why is an alignment needed here at all? And why 4 aligned?
For RV32 S-mode, the physical address space is 34bits wide but "unsigned long" is 32bits wide. This is because Sv32 PTEs allow 34bits of PPN. In fact, even instructions such as HFENCE.GVMA have this "address right shift by 2" requirement based on this rationale.
The shared memory area should be normal cacheable memory for the supervisor-mode software. Also, the shared memory area is global across all HARTs so SBI implementation must ensure atomicity in setting the shared memory area.
Errors: SBI_SUCCESS - Shared memory area set successfully. SBI_ERR_INVALID_ADDRESS - The shared memory area pointed by `addr_div_by_2` and `size` parameters is not normal cacheable memory or not accessible to supervisor-mode software.
struct sbiret sbi_debug_console_puts(unsigned long area_offset, unsigned long num_chars)
I would prefer to simply pass a physical address pointer here with no requirements on alignment. And no prior SBI call.
sbi_debug_console_set_area() might be called with different values by different threads. An offset is ambiguous as it does not define to which of the different shared areas it relates. Please, use a pointer.
Do we need num_chars? Are we expecting to provide binary output? Using 0x00 as terminator would be adequate in most cases.
Bare-metal tests (or assembly sources) can print sub-strings from a large per-populated string in shared memory. Assuming that string is always terminated by 0x00 in sbi_debug_console_puts() will break this flexibility.
OK
What is the requirement on the console? Does it have to support 8bit output to allow for UTF-8?
We need to clarify this. Suggestions ?
The platform specification would be the right place to require 8-bit support for the console.
Do we make any assumptions about encoding?
Same as above, this needs more clarification. Suggestions ?
We should add to the platform specification that UTF-8 output is assumed on the serial console.
I am of the opinion to keep such encoding related assumptions to be minimal.
How would we handle a console set up to 7bit + parity if a character > 0x7f is sent?
I would consider this to be part of the clarification we add for encoding.
We should state if extra bits are ignored or the bytes are not send. The easiest thing is to just ignore the extra bits. So let't state this here.
Best regards
Heinrich
Print the string specified by `area_offset` and `num_chars` on the debug console. The `area_offset` parameter is the start of string in the shard memory area whereas `num_chars` parameter
%s/shard/shared/
Okay, I will update.
is the number of characters (or bytes) in the string.
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 start of the string (i.e. `area_offset`) or end of the string (i.e. `area_offset + num_chars`) is outside shared memory area.
There could be other reasons of failures:
* set up of the UART failed in OpenSBI * no UART defined in the device-tree * ...
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:
Thanks for starting to close this gap.
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.
I miss a discussion of the conflicts that can arise if the configuration of the serial console is changed by the caller.
Do we need an ecall that closes the SBI console to further access?
Usually, the serial port related code in M-mode firmware only uses status and data registers so for most serial ports support the M-mode firmware will adapt to serial port configuration changes.
In fact, this is why we never had a special SBI call for serial port reconfiguration in legacy SBI v0.1 as well.
In case of virtualization, the serial port (or console) is emulated so the special SBI call is not useful for virtualization.
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.
Isn't it M-mode software that has to program the MMU to allow all harts in M-mode and S-mode access to the memory area? What is the S-mode software to do about the memory area prior to calling sbi_debug_console_set_area()?
Actually, it's the S-mode software which is voluntarily giving a portion of its memory to be used as shared memory. The proposal only mandates that whatever memory is selected by S-mode software should be a regular cacheable memory (not IO memory). Also, if Svpbmt is available then S-mode software should only use memory type 0 in the PTEs.
Function: Set Console Area (FID #0) -----------------------------------
struct sbiret sbi_debug_console_set_area(unsigned long addr_div_by_4, unsigned long size)
The console output is needed on the very start of the S-mode software, before setting up anything.
Can we avoid this extra function?
Can we simply assume that the caller of sbi_debug_console_puts() provides a physical address pointer to a memory area that is suitable?
Theoretically, we can avoid the extra function to set shared memory area but it will complicate things in future when we have supervisor software encrypting it's own memory (using special ISA support) because in this case supervisor software will have to unprotect memory every time the sbi_debug_console_puts() is called and protect it again after the call.
Currently this function is just a nop(). It is not needed in this revision of the extension.
The function might be called repeatedly by different threads with different values. How do you want to keep track of all of these different areas?
Memory shared between different security realms will arise in many different scenarios. As this is not console specific it should be in a separate extension. That extension should be defined once we have clarity about how security realms are managed.
I would like to understand more about the security concerns you raised. Can you please elaborate on this ?
I have no security concerns. My thought was that it might be better to manage shared memory in a separate extension for all use cases.
Best regards
Heinrich
As you pointed out, there are other possible use cases(e.g STA, PMU) for shared memory between S & M mode or VS & HS mode. It would be good to address these concerns right now instead of discussing those in each individual extension context.
Set the shared memory area specified by `addr_div_by_2` and `size`
%s/addr_div_by_2/addr_div_by_4/
Okay, I will update.
parameters. The `addr_div_by_4` parameter is base address of the
%s/is base/is the base/
Okay, I will update.
shared memory area right shifted by 2 whereas `size` parameter is the size of shared memory area in bytes.
Why shifting the address? I would prefer to keep it simple for the caller. If the alignment is not suitable, return an error.
But why is an alignment needed here at all? And why 4 aligned?
For RV32 S-mode, the physical address space is 34bits wide but "unsigned long" is 32bits wide. This is because Sv32 PTEs allow 34bits of PPN. In fact, even instructions such as HFENCE.GVMA have this "address right shift by 2" requirement based on this rationale.
The shared memory area should be normal cacheable memory for the supervisor-mode software. Also, the shared memory area is global across all HARTs so SBI implementation must ensure atomicity in setting the shared memory area.
Errors: SBI_SUCCESS - Shared memory area set successfully. SBI_ERR_INVALID_ADDRESS - The shared memory area pointed by `addr_div_by_2` and `size` parameters is not normal cacheable memory or not accessible to supervisor-mode software.
struct sbiret sbi_debug_console_puts(unsigned long area_offset, unsigned long num_chars)
I would prefer to simply pass a physical address pointer here with no requirements on alignment. And no prior SBI call.
sbi_debug_console_set_area() might be called with different values by different threads. An offset is ambiguous as it does not define to which of the different shared areas it relates. Please, use a pointer.
Do we need num_chars? Are we expecting to provide binary output? Using 0x00 as terminator would be adequate in most cases.
Bare-metal tests (or assembly sources) can print sub-strings from a large per-populated string in shared memory. Assuming that string is always terminated by 0x00 in sbi_debug_console_puts() will break this flexibility.
OK
What is the requirement on the console? Does it have to support 8bit output to allow for UTF-8?
We need to clarify this. Suggestions ?
The platform specification would be the right place to require 8-bit support for the console.
Do we make any assumptions about encoding?
Same as above, this needs more clarification. Suggestions ?
We should add to the platform specification that UTF-8 output is assumed on the serial console.
I am of the opinion to keep such encoding related assumptions to be minimal.
How would we handle a console set up to 7bit + parity if a character > 0x7f is sent?
I would consider this to be part of the clarification we add for encoding.
We should state if extra bits are ignored or the bytes are not send. The easiest thing is to just ignore the extra bits. So let't state this here.
Best regards
Heinrich
Print the string specified by `area_offset` and `num_chars` on the debug console. The `area_offset` parameter is the start of string in the shard memory area whereas `num_chars` parameter
%s/shard/shared/
Okay, I will update.
is the number of characters (or bytes) in the string.
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 start of the string (i.e. `area_offset`) or end of the string (i.e. `area_offset + num_chars`) is outside shared memory area.
There could be other reasons of failures:
* set up of the UART failed in OpenSBI * no UART defined in the device-tree * ...
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:
Thanks for starting to close this gap.
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.
I miss a discussion of the conflicts that can arise if the configuration of the serial console is changed by the caller.
Do we need an ecall that closes the SBI console to further access?
Usually, the serial port related code in M-mode firmware only uses status and data registers so for most serial ports support the M-mode firmware will adapt to serial port configuration changes.
In fact, this is why we never had a special SBI call for serial port reconfiguration in legacy SBI v0.1 as well.
In case of virtualization, the serial port (or console) is emulated so the special SBI call is not useful for virtualization.
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.
Isn't it M-mode software that has to program the MMU to allow all harts in M-mode and S-mode access to the memory area? What is the S-mode software to do about the memory area prior to calling sbi_debug_console_set_area()?
Actually, it's the S-mode software which is voluntarily giving a portion of its memory to be used as shared memory. The proposal only mandates that whatever memory is selected by S-mode software should be a regular cacheable memory (not IO memory). Also, if Svpbmt is available then S-mode software should only use memory type 0 in the PTEs.
Function: Set Console Area (FID #0) -----------------------------------
struct sbiret sbi_debug_console_set_area(unsigned long addr_div_by_4, unsigned long size)
The console output is needed on the very start of the S-mode software, before setting up anything.
Can we avoid this extra function?
Can we simply assume that the caller of sbi_debug_console_puts() provides a physical address pointer to a memory area that is suitable?
Theoretically, we can avoid the extra function to set shared memory area but it will complicate things in future when we have supervisor software encrypting it's own memory (using special ISA support) because in this case supervisor software will have to unprotect memory every time the sbi_debug_console_puts() is called and protect it again after the call.
Currently this function is just a nop(). It is not needed in this revision of the extension.
The function might be called repeatedly by different threads with different values. How do you want to keep track of all of these different areas?
Memory shared between different security realms will arise in many different scenarios. As this is not console specific it should be in a separate extension. That extension should be defined once we have clarity about how security realms are managed.
I would like to understand more about the security concerns you raised. Can you please elaborate on this ?
As you pointed out, there are other possible use cases(e.g STA, PMU) for shared memory between S & M mode or VS & HS mode. It would be good to address these concerns right now instead of discussing those in each individual extension context.
Set the shared memory area specified by `addr_div_by_2` and `size`
%s/addr_div_by_2/addr_div_by_4/
Okay, I will update.
parameters. The `addr_div_by_4` parameter is base address of the
%s/is base/is the base/
Okay, I will update.
shared memory area right shifted by 2 whereas `size` parameter is the size of shared memory area in bytes.
Why shifting the address? I would prefer to keep it simple for the caller. If the alignment is not suitable, return an error.
But why is an alignment needed here at all? And why 4 aligned?
For RV32 S-mode, the physical address space is 34bits wide but "unsigned long" is 32bits wide. This is because Sv32 PTEs allow 34bits of PPN. In fact, even instructions such as HFENCE.GVMA have this "address right shift by 2" requirement based on this rationale.
The shared memory area should be normal cacheable memory for the supervisor-mode software. Also, the shared memory area is global across all HARTs so SBI implementation must ensure atomicity in setting the shared memory area.
Errors: SBI_SUCCESS - Shared memory area set successfully. SBI_ERR_INVALID_ADDRESS - The shared memory area pointed by `addr_div_by_2` and `size` parameters is not normal cacheable memory or not accessible to supervisor-mode software.
struct sbiret sbi_debug_console_puts(unsigned long area_offset, unsigned long num_chars)
I would prefer to simply pass a physical address pointer here with no requirements on alignment. And no prior SBI call.
sbi_debug_console_set_area() might be called with different values by different threads. An offset is ambiguous as it does not define to which of the different shared areas it relates. Please, use a pointer.
Do we need num_chars? Are we expecting to provide binary output? Using 0x00 as terminator would be adequate in most cases.
Bare-metal tests (or assembly sources) can print sub-strings from a large per-populated string in shared memory. Assuming that string is always terminated by 0x00 in sbi_debug_console_puts() will break this flexibility.
OK
What is the requirement on the console? Does it have to support 8bit output to allow for UTF-8?
We need to clarify this. Suggestions ?
The platform specification would be the right place to require 8-bit support for the console.
Do we make any assumptions about encoding?
Same as above, this needs more clarification. Suggestions ?
We should add to the platform specification that UTF-8 output is assumed on the serial console.
I am of the opinion to keep such encoding related assumptions to be minimal.
How would we handle a console set up to 7bit + parity if a character > 0x7f is sent?
I would consider this to be part of the clarification we add for encoding.
We should state if extra bits are ignored or the bytes are not send. The easiest thing is to just ignore the extra bits. So let't state this here.
Best regards
Heinrich
Print the string specified by `area_offset` and `num_chars` on the debug console. The `area_offset` parameter is the start of string in the shard memory area whereas `num_chars` parameter
%s/shard/shared/
Okay, I will update.
is the number of characters (or bytes) in the string.
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 start of the string (i.e. `area_offset`) or end of the string (i.e. `area_offset + num_chars`) is outside shared memory area.
There could be other reasons of failures:
* set up of the UART failed in OpenSBI * no UART defined in the device-tree * ...
On Fri, Jun 3, 2022 at 2:35 AM Stefano Stabellini <stefano.stabellini@...> wrote:
On Thu, 2 Jun 2022, Greg Favor wrote:
On Thu, Jun 2, 2022 at 1:29 PM Stefano Stabellini <stefano.stabellini@...> wrote: On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote: > Of course a console is needed. But I was questioning the need for something much > more elaborate than a putchar/getchar interface. I understand its needed to port > the hypervisor but I undersatnd it would be needed for very early parts of the > hypervisor where it does not even have the ability to master a uart on its own.
Yeah, I think you are right that it is not a must-have feature but a nice-to-have feature.
Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have found that to be a risky presumption in certain production environments where boot time matters (especially with frequent standing up of VMs from scratch). So a worthwhile sanity check question would be 1) what percentage of early boot time is spent writing to the console with per-string SBI calls, and 2) by what order of magnitude does that percentage inflate due to SBI calls for every individual character.
The numbers you asked will help but I just wanted to add that in my opinion a per-character putchar interface is not suitable for production due to the reasons you mentioned. I would compile it out in non-DEBUG builds.
On the other hand the per-string print interface might be usable in production, even not just early boot. However, of course, a proper UART driver would be even better.
This is why I think it is nice to have: it expands the potential uses of the SBI console interface, and it is simple and easy to use. At the same time it is not a must-have because you could get away with just putchat in early boot for DEBUG builds, and nothing + UART driver in non-DEBUG builds.
That is why I am in favor of this addition, although I recognize it is not critical.
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.
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.
On Thu, Jun 2, 2022 at 1:29 PM Stefano Stabellini <stefano.stabellini@...> wrote: On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote: > Of course a console is needed. But I was questioning the need for something much > more elaborate than a putchar/getchar interface. I understand its needed to port > the hypervisor but I undersatnd it would be needed for very early parts of the > hypervisor where it does not even have the ability to master a uart on its own.
Yeah, I think you are right that it is not a must-have feature but a nice-to-have feature.
Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have found that to be a risky presumption in certain production environments where boot time matters (especially with frequent standing up of VMs from scratch). So a worthwhile sanity check question would be 1) what percentage of early boot time is spent writing to the console with per-string SBI calls, and 2) by what order of magnitude does that percentage inflate due to SBI calls for every individual character.
The numbers you asked will help but I just wanted to add that in my opinion a per-character putchar interface is not suitable for production due to the reasons you mentioned. I would compile it out in non-DEBUG builds.
On the other hand the per-string print interface might be usable in production, even not just early boot. However, of course, a proper UART driver would be even better.
This is why I think it is nice to have: it expands the potential uses of the SBI console interface, and it is simple and easy to use. At the same time it is not a must-have because you could get away with just putchat in early boot for DEBUG builds, and nothing + UART driver in non-DEBUG builds.
That is why I am in favor of this addition, although I recognize it is not critical.
On Thu, Jun 02, 2022 at 01:50:01PM -0700, Greg Favor wrote:
On Thu, Jun 2, 2022 at 1:29 PM Stefano Stabellini < stefano.stabellini@...> wrote:
On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote:
Of course a console is needed. But I was questioning the need for
something much
more elaborate than a putchar/getchar interface. I understand its needed
to port
the hypervisor but I undersatnd it would be needed for very early parts
of the
hypervisor where it does not even have the ability to master a uart on
its own.
Yeah, I think you are right that it is not a must-have feature but a nice-to-have feature.
Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have found that to be a risky presumption in certain production environments where boot time matters (especially with frequent standing up of VMs from scratch). So a worthwhile sanity check question would be 1) what percentage of early boot time is spent writing to the console with per-string SBI calls, and 2) by what order of magnitude does that percentage inflate due to SBI calls for every individual character.
I think the extension was proposed to be a Debug console extension.
In a production environment if 10's of VMs were booting having them emit to the physical console - where all of those outputs will get interspersed seems to be not so useful. In a production environment would we expect the VMM to provide a console service and not need SBI calls into M-mode firmare to emit VM output to a physical console?
I was thinking this was about early boot debug and not so much about needing a console at early boot. In most production deployments there may not be someone sitting at a terminal watching prints and so it may make more sense for VM console outputs to be logged into a persistent file somewhere for example. Or be held in the VM itself - e.g. a kernel ring buffer that someone may want to display using a tool like dmesg when needed but otherwise does not get emitted chattily to a physical console.
On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote: > Of course a console is needed. But I was questioning the need for something much
> more elaborate than a putchar/getchar interface. I understand its needed to port
> the hypervisor but I undersatnd it would be needed for very early parts of the
> hypervisor where it does not even have the ability to master a uart on its own.
Yeah, I think you are right that it is not a must-have feature but a
nice-to-have feature.
Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have found that to be a risky presumption in certain production environments where boot time matters (especially with frequent standing up of VMs from scratch). So a worthwhile sanity check question would be 1) what percentage of early boot time is spent writing to the console with per-string SBI calls, and 2) by what order of magnitude does that percentage inflate due to SBI calls for every individual character.
Starting at 1% and inflating to 10%-100% would not be good. Starting at 0.01% and inflating to 0.1-1% is likely acceptable.
On Thu, 2 Jun 2022, Vedvyas Shanbhogue via lists.riscv.org wrote:
Of course, if a hypervisor is already available for the board, then it would be just as easy to use a paravirtualized interface, e.g. Xen's HYPERVISOR_console_io hypercall. But somebody has to port the hypervisor first :-)
Of course a console is needed. But I was questioning the need for something much more elaborate than a putchar/getchar interface. I understand its needed to port the hypervisor but I undersatnd it would be needed for very early parts of the hypervisor where it does not even have the ability to master a uart on its own.
Yeah, I think you are right that it is not a must-have feature but a nice-to-have feature.
