Console legacy functions have not been migrated to standard extension format about riscv-sbi-doc

[avpatel]

For Hypervisor, you can emulate UART8250 or SiFive UART for Guest or VM. We are already doing this for KVM RISC-V and Xvisor RISC-V.

From hypervisors perspective, we really don't need any SBI console calls.

Regards,
Anup

[JohnAZoidberg]

Sounds like they're not coming back: https://lore.kernel.org/patchwork/cover/1119999/

[atishp04]

The idea is to deprecate them in future because you can use earlycon devices in Linux.

[fintelia]

SBI of course doesn't just cater to Linux but you'd have the same issue on basically any other operating system too: Sharing a UART or console device between the OS and the SBI provider could result in them interfering with each other. UEFI has a clear hand-off point to coordinate who in charge of managing I/O devices (the ExitBootServices function), but since SBI doesn't have anything equivalent it makes more sense to remove these functions entirely. Effectively, the hand-off takes place as soon as the OS starts

[konrad-schwarz]

Actually, for the hypervisor I am porting, my plan was to continue to use the SBI as the interface to the system console, even after boot. Similarly, guest operating systems could access the console, at least for logging, via the SBI, providing for a – very simple – multiplexing of the console. Clearly, the SBI console itself does not actually have to be tied to a physical UART/RS-232 interface, but could be implemented via the debug interface (JTAG/trace – I haven’t looked at the RISC-V debug specification yet) or through some sort of Serial-over-LAN out-of-band management protocol. The extreme simplicity of the console API makes this easy to do. Obviously better APIs, such as VirtIO(?) can be envisioned for virtualized consoles. From: Jonathan Behrens <[email protected]> Sent: Wednesday, March 4, 2020 22:02 To: riscv/riscv-sbi-doc <[email protected]> Cc: Schwarz, Konrad (CT RDA IOT SES-DE) <[email protected]>; Author <[email protected]> Subject: Re: [riscv/riscv-sbi-doc] Console legacy functions have not been migrated to standard extension format (#34) SBI of course doesn't just cater to Linux but you'd have the same issue on basically any other operating system too: Sharing a UART or console device between the OS and the SBI provider could result in them interfering with each other. UEFI has a clear hand-off point to coordinate who in charge of managing I/O devices (the ExitBootServices function), but since SBI doesn't have anything equivalent it makes more sense to remove these functions entirely. Effectively, the hand-off takes place as soon as the OS starts — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#34>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAGVI65D63QGDC5TCNPZXG3RF26UVANCNFSM4LBHUW4A>.

[konrad-schwarz]

The SBI specification should be extended to note that the console functions are expected to be deprecated.

[avpatel]

The SBI specification should be extended to note that the console functions are expected to be deprecated.

I agree. We need a short paragraph at the end of "Legacy SBI Extension, Extension IDs 0x00 through 0x0F". We should clearly state that we have SBI Extensions to replace almost all Legacy SBI functions except SBI console calls. The rationale for not supporting console functions as SBI Extension is to avoid duplicating early debugging features (such as Linux earlycon) of modern OSes.

Can you send a PR to riscv-sbi-doc ?

Regards,
Anup

[atishp04]

The issue is already addressed in the specification as per the latest suggestion. Closing this.

[bog-dan-ro]

IMHO having at least console putchar functionality is a very nice to have feature in SBI. Is not useful only for bare-metal apps, but also it will help microkernels to stay micro. Otherwise they need to parse the FDT, find what is the /chosen/std-out node, parse that node, then check if it's compatible with the supported drivers.