Date
1 - 2 of 2
[sig-hypervisors] SBI Debug Console Extension Proposal (Draft v1)
Schwarz, Konrad <konrad.schwarz@...>
Hi Anup,
* Guest memory access: I think this would be the first SBI extension to require access to
guest memory. This needs to be considered carefully, but I think the higher bandwidth afforded by
the interface is useful enough to allow this.
* API:
* Currently, only a write interface is provided. It would be much better to have a
read/write interface.
Benefits of this would be to allow a hypervisor to control an OS, e.g., for testing purposes
or to automate installation tasks. Inter-guest communication could also be realized
via such an interface.
* As the relationship between SBI and OS is the same as OS and user process, an interface
in the style of e.g., Unix IO is possible.
* Global shared memory buffer design and alternatives:
The API should have per read() or write() parameters for buffer address and length.
This makes it easy for different parts of the OS kernel to output strings directly,
without requiring thread synchronization of the shared buffer used by the present proposal.
A single buffer (i.e., shared memory) will in most SW architectures require an
extra copying of the formatted output string into the shared memory region, which
would be avoided using per read()/write() call parameters.
The exact same argument applies to the SBI implementation: a multi-hart machine
utilizing a single shared memory block to communicate with S-mode software
will require m-mode thread synchronization when accessing the block.
Having only a single shared memory block will lead to scaling problems
on high hart count machines.
I see no advantages of the proposed design to dedicate a block of memory to
I/O in advance (and no modern API does this).
The SBI implementation will still need to be prepared to handle
access faults on each read and write call, there is no amortization of one-time costs
regarding address translation or permission checking that I see. In the H-extension,
the guest memory access instructions are as effective as possible, for M-mode code,
I'm sure that efficient access to S-mode virtual addresses is possible as well.
(Or the convention can be made that addresses are specified as guest-physical,
which should be avoided if efficient alternatives are available in RISC-V.
Note that the draft proposal does not speak of this at all).
* Multiple device support: a parameter should be allocated to allow the OS to
select which of possibly several output devices to utilize, like the "file
descriptor" parameter of the POSIX read()/write() interface.
This raises the question of binding these file descriptors to physical devices,
but a start could be made in analogy to Unix (again), where devices 0, 1, 2 are
assigned to standard in, standard out, and standard error, and in many cases
will be attached to the same physical device, and that are pre-opened when the
OS starts. As in Unix, the semantics of these would be roughly defined,
but an OS could write out its boot logging strings to 2, and drive an interactive
console process (such as a shell) from 0 and 1.
The question of binding string-valued names to file descriptor (open()) and
closing them, etc., could be deferred to a later date and possibly
be implementation defined.
* Asynchronicity and flow control: Unix solves this (poorly) via select()
or the SIGIO signal. If SBI introduces an interface for this, this will need to
co-exist with the OS scheduling that is largely driven by the interrupt controller,
which is a hard thing to do.
I think that the SBI interface should
be best effort, copying all data from the client immediately (as Unix does):
when buffer space in the SBI implementation is exhausted,
it should return short counts; if the SBI client is prepared to wait, a blocking
flush call could be added, which returns when some measure space is
available in the SBI implementation's output buffers (or when input is available).
The existing Unix interfaces for this can again be used as a guide; they
should be mature enough to cover all relevant cases.
For highest performance, an S-mode interrupt could be synthesized by the
SBI implementation when buffer space is available.
With best regards,
Konrad Schwarz
Siemens AG
T CED SES-DE
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 (89) 7805-22579
Fax.: +49 (89) 636-33045
Mobile: +49 (1522) 8864636
mailto:konrad.schwarz@...
www.siemens.com
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
From: sig-hypervisors@... <sig-hypervisors@...> On Behalf Of Anup Patel viaHere are my thoughts:
lists.riscv.org
Subject: [sig-hypervisors] SBI Debug Console Extension Proposal (Draft v1)
Below is the draft proposal for SBI Debug Console Extension.
* Guest memory access: I think this would be the first SBI extension to require access to
guest memory. This needs to be considered carefully, but I think the higher bandwidth afforded by
the interface is useful enough to allow this.
* API:
* Currently, only a write interface is provided. It would be much better to have a
read/write interface.
Benefits of this would be to allow a hypervisor to control an OS, e.g., for testing purposes
or to automate installation tasks. Inter-guest communication could also be realized
via such an interface.
* As the relationship between SBI and OS is the same as OS and user process, an interface
in the style of e.g., Unix IO is possible.
* Global shared memory buffer design and alternatives:
The API should have per read() or write() parameters for buffer address and length.
This makes it easy for different parts of the OS kernel to output strings directly,
without requiring thread synchronization of the shared buffer used by the present proposal.
A single buffer (i.e., shared memory) will in most SW architectures require an
extra copying of the formatted output string into the shared memory region, which
would be avoided using per read()/write() call parameters.
The exact same argument applies to the SBI implementation: a multi-hart machine
utilizing a single shared memory block to communicate with S-mode software
will require m-mode thread synchronization when accessing the block.
Having only a single shared memory block will lead to scaling problems
on high hart count machines.
I see no advantages of the proposed design to dedicate a block of memory to
I/O in advance (and no modern API does this).
The SBI implementation will still need to be prepared to handle
access faults on each read and write call, there is no amortization of one-time costs
regarding address translation or permission checking that I see. In the H-extension,
the guest memory access instructions are as effective as possible, for M-mode code,
I'm sure that efficient access to S-mode virtual addresses is possible as well.
(Or the convention can be made that addresses are specified as guest-physical,
which should be avoided if efficient alternatives are available in RISC-V.
Note that the draft proposal does not speak of this at all).
* Multiple device support: a parameter should be allocated to allow the OS to
select which of possibly several output devices to utilize, like the "file
descriptor" parameter of the POSIX read()/write() interface.
This raises the question of binding these file descriptors to physical devices,
but a start could be made in analogy to Unix (again), where devices 0, 1, 2 are
assigned to standard in, standard out, and standard error, and in many cases
will be attached to the same physical device, and that are pre-opened when the
OS starts. As in Unix, the semantics of these would be roughly defined,
but an OS could write out its boot logging strings to 2, and drive an interactive
console process (such as a shell) from 0 and 1.
The question of binding string-valued names to file descriptor (open()) and
closing them, etc., could be deferred to a later date and possibly
be implementation defined.
* Asynchronicity and flow control: Unix solves this (poorly) via select()
or the SIGIO signal. If SBI introduces an interface for this, this will need to
co-exist with the OS scheduling that is largely driven by the interrupt controller,
which is a hard thing to do.
I think that the SBI interface should
be best effort, copying all data from the client immediately (as Unix does):
when buffer space in the SBI implementation is exhausted,
it should return short counts; if the SBI client is prepared to wait, a blocking
flush call could be added, which returns when some measure space is
available in the SBI implementation's output buffers (or when input is available).
The existing Unix interfaces for this can again be used as a guide; they
should be mature enough to cover all relevant cases.
For highest performance, an S-mode interrupt could be synthesized by the
SBI implementation when buffer space is available.
With best regards,
Konrad Schwarz
Siemens AG
T CED SES-DE
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 (89) 7805-22579
Fax.: +49 (89) 636-33045
Mobile: +49 (1522) 8864636
mailto:konrad.schwarz@...
www.siemens.com
Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
Stefano Stabellini
On Thu, 2 Jun 2022, Schwarz, Konrad via lists.riscv.org wrote:
HYPERVISOR_console_io. The first parameter is the operation:
CONSOLEIO_write or CONSOLEIO_read.
The interface in RISC-V spec language would be something along these
lines:
struct sbiret sbi_debug_console_io(unsigned long operation, /* read or write */
unsigned long address,
unsigned long num_chars)
There is no memory area pre-registration required, however appropriate
checks on the validity of the address provided should always be done in
the implementation.
The good thing about getting rid of the pre-registration is that
multiple threads could make concurrent sbi_debug_console_io requests on
different CPUs.
I think it might be a good idea in the guest-side implementation (e.g.
Linux or Zephyr) to choose a specific memory area for this. However, it
doesn't have to be part of the interface. I think it should be an
implementation detail.
The firmware/hypervisor-side implementation of sbi_debug_console_io
can deal with any addresses provided as long as they are valid.
Hi Anup,From: sig-hypervisors@... <sig-hypervisors@...> On Behalf Of Anup Patel viaHere are my thoughts:
lists.riscv.org
Subject: [sig-hypervisors] SBI Debug Console Extension Proposal (Draft v1)
Below is the draft proposal for SBI Debug Console Extension.
* Guest memory access: I think this would be the first SBI extension to require access to
guest memory. This needs to be considered carefully, but I think the higher bandwidth afforded by
the interface is useful enough to allow this.
* API:This could be done. As an example Xen provides the hypercall
* Currently, only a write interface is provided. It would be much better to have a
read/write interface.
Benefits of this would be to allow a hypervisor to control an OS, e.g., for testing purposes
or to automate installation tasks. Inter-guest communication could also be realized
via such an interface.
HYPERVISOR_console_io. The first parameter is the operation:
CONSOLEIO_write or CONSOLEIO_read.
The interface in RISC-V spec language would be something along these
lines:
struct sbiret sbi_debug_console_io(unsigned long operation, /* read or write */
unsigned long address,
unsigned long num_chars)
There is no memory area pre-registration required, however appropriate
checks on the validity of the address provided should always be done in
the implementation.
The good thing about getting rid of the pre-registration is that
multiple threads could make concurrent sbi_debug_console_io requests on
different CPUs.
I think it might be a good idea in the guest-side implementation (e.g.
Linux or Zephyr) to choose a specific memory area for this. However, it
doesn't have to be part of the interface. I think it should be an
implementation detail.
The firmware/hypervisor-side implementation of sbi_debug_console_io
can deal with any addresses provided as long as they are valid.