|
Re: SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Darius Rad
·
#1750
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
By
Schwarz, Konrad <konrad.schwarz@...>
·
#1749
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Alistair Francis
·
#1748
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
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.
Consider
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.
Consider
|
By
Schwarz, Konrad <konrad.schwarz@...>
·
#1747
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
A further use case requiring fast boot
are automotive electronic control units, e.g.,
an infotainment unit.
--
Konrad
From: sig-hypervisors@... <sig-hypervisors@...>On Behalf Of Greg Favor
A further use case requiring fast boot
are automotive electronic control units, e.g.,
an infotainment unit.
--
Konrad
From: sig-hypervisors@... <sig-hypervisors@...>On Behalf Of Greg Favor
|
By
Schwarz, Konrad <konrad.schwarz@...>
·
#1746
·
|
|
Re: SBI Debug Console Extension Proposal (Draft v1)
<heinrich.schuchardt@...> wrote:
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
<heinrich.schuchardt@...> wrote:
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
|
By
atishp@...
·
#1745
·
|
|
Re: SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Heinrich Schuchardt
·
#1744
·
|
|
Re: SBI Debug Console Extension Proposal (Draft v1)
<heinrich.schuchardt@...> wrote:
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
<heinrich.schuchardt@...> wrote:
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
|
By
atishp@...
·
#1743
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
Hi Stefano,
<stefano.stabellini@...> wrote:
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
Hi Stefano,
<stefano.stabellini@...> wrote:
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
|
By
Anup Patel
·
#1742
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Stefano Stabellini
·
#1741
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Ved Shanbhogue
·
#1740
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Greg Favor
·
#1739
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
Yeah, I think you are right that it is not a must-have feature but a
nice-to-have feature.
Yeah, I think you are right that it is not a must-have feature but a
nice-to-have feature.
|
By
Stefano Stabellini
·
#1738
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
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
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
|
By
Ved Shanbhogue
·
#1737
·
|
|
Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
That is because it is useful to have debug console output when porting a
hypervisor or baremetal code to a new board.
Of course, if a hypervisor is already available for the board, then it
would be
That is because it is useful to have debug console output when porting a
hypervisor or baremetal code to a new board.
Of course, if a hypervisor is already available for the board, then it
would be
|
By
Stefano Stabellini
·
#1736
·
|
|
Re: [sig-hypervisors] SBI Debug Console Extension Proposal (Draft v1)
This could be done. As an example Xen provides the hypercall
HYPERVISOR_console_io. The first parameter is the operation:
CONSOLEIO_write or CONSOLEIO_read.
The interface in RISC-V spec language
This could be done. As an example Xen provides the hypercall
HYPERVISOR_console_io. The first parameter is the operation:
CONSOLEIO_write or CONSOLEIO_read.
The interface in RISC-V spec language
|
By
Stefano Stabellini
·
#1735
·
|
|
Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)
It's also helpful in early board bringup and early debugging as
pointed out by Heiko as well.
To address some of the concerns raised above, how about putting some
restrictions on
It's also helpful in early board bringup and early debugging as
pointed out by Heiko as well.
To address some of the concerns raised above, how about putting some
restrictions on
|
By
atishp@...
·
#1734
·
|
|
Re: SBI Debug Console Extension Proposal (Draft v1)
We have a requirement in the OS-A platform spec to mandate a particular type
of UART for early prints but there were objections on selecting one type of UART
over another.
This SBI debug console
We have a requirement in the OS-A platform spec to mandate a particular type
of UART for early prints but there were objections on selecting one type of UART
over another.
This SBI debug console
|
By
Anup Patel
·
#1733
·
|
|
Re: SBI changes
Mark,
In case you missed it from the agenda-email: we have the formation of
a Firmware & Platforms Services SIG on the agenda for the (joint)
Software HCs meeting today. Atish has kindly volunteered
Mark,
In case you missed it from the agenda-email: we have the formation of
a Firmware & Platforms Services SIG on the agenda for the (joint)
Software HCs meeting today. Atish has kindly volunteered
|
By
Philipp Tomsich
·
#1732
·
|
|
Re: SBI changes
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
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
|
By
mark
·
#1731
·
|