Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

Hello Zheng,

On 9/29/26 5:10 AM, Zhang Zheng wrote:
> On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote:
> > On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote:
> > > On 9/28/26 10:40 AM, Zhang Zheng wrote:
> > > > On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
> > > > > On 9/28/26 4:38 AM, Zhang Zheng wrote:
> > > > > > The legacy SBI console extension is planned for deprecation. Replace the
> > > > > > RISC-V early printk backend with direct access to 8250 UART MMIO.
> > > > > Won't it better just to start to add support of newer SBI? It provides
> > > > > pretty good support + faster as it supports passing of string instead of one
> > > > > char.
> > > > Using the newer SBI DBCN extension would indeed result in a smaller change. At
> > > > the time, I mainly followed the direction suggested by the TODO and referred
> > > > directly to the arm64 implementation, from which most of the code was adapted.
> > > I think TODO was written at that way because I missed DBCN (or it wasn't
> > > ratified at that moment). Considering that it is ratified now ...
> > >
> > > > > Also, I think it will lead to lesser changes.
> > > > If falling back to SBI console putchar is acceptable, DBCN should work
> > > > well here.
> > > ... I prefer to use SBI functionality (in the current case DBCN) as maximum
> > > as possible so if there is no any reason (and I don't see at the moment it)
> > > which doesn't allow us to use DBCN here, I would prefer to use DBCN.
> > Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware,
> > which should ship with a recent version of OpenSBI, I think you are right that
> > there is no real need to provide a fallback here.
> >
> > > If you still want to in the way suggested by TODO then some parts which are
> > > common between Arm and RISC-V should be moved to common instead of
> > > introducing them in RISC-V specific folder.
> > I also tried to make the current patch as minimal as possible, but it would
> > still end up touching quite a few places.
> >
> > > Let me know which approach you are going to follow. If the current one you
> > > already introduced then I will start to review it, if you will go SBI-way
> > > then I prefer to wait for your v2.
> > >
> > > ~ Oleksii
> > I misunderstood the TODO comment, I thought that would be the preferred
> > implementation. Therefore, I will switch to using DBCN and send a v2.
I think I didn’t word it in the best way.

For early debug, I think it would be better to use the SBI function. At 
some point, it doesn’t really matter which one we use, SBI 0.1 or DBCN. 
If we switch to using the UART’s MMIO directly, we wouldn’t need to 
change the privilege mode or perform a context switch, so it should be 
faster.
However, considering that the early console is mainly used during 
bring-up, it seems like the overhead of an SBI function call isn’t a big 
price to pay. In return, we could potentially have early printk support 
even for UARTs that aren’t currently supported by Xen.
> > Best regards,
> >
> > Zhang
> Hi Oleksii,
>
> I initially assumed that the DBCN console-write call would wait until the
> whole string had been transmitted. After checking the SBI specification
> and the Linux implementation, I found that this is not the case.
I think Linux does roughly the same here: its SBI earlycon
calls sbi_debug_console_write() (or something like that) in a loop until 
the whole buffer has been written.
Also note that Linux supports both the legacy SBI v0.1 console_putchar
and DBCN console write for earlycon. It picks DBCN when the firmware
provides it and falls back to v0.1 otherwise (when CONFIG_RISCV_SBI_V01
is enabled). I would really like Xen to do the same rather than drop
SBI v0.1 support. A board might not support DBCN, or might implement 
only the legacy SBI extensions, and we still want console output there. 
So we should keep both.
I'd go further: we probably don't need to add DBCN support at this point.
It would be enough to fix the bug you originally hit with the legacy SBI
call.

Also, in Linux the SBI console is only used as an early (boot) console.
Once the UART driver has probed and registered a real console, printk
switches to it and unregisters the boot console (unless keep_bootcon is
passed). So this switch doesn't cause any issues in Linux, and I don't 
see why it should be a problem in our case either. Switching to DBCN, or 
the approach taken in the current patch, looks to me like it is just 
hiding an issue somewhere else.
> The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN
> through the HVC console driver, so the DBCN backend remains the owner of the
> console and the 8250 driver does not subsequently reinitialize the same UART
> or clear its FIFO.
>
> On the other hand, when Linux uses an 8250 earlycon, it accesses the UART
> directly and waits for UART_LSR_TEMT before the regular 8250 driver takes
> over.
>
> The current Xen setup combines these two paths: early printk uses the SBI
> console, while the later 8250 driver initializes the same UART. During this
> handover, the 8250 driver clears the TX FIFO, which can discard characters
> that were accepted by SBI but have not yet been transmitted by the UART.
Isn't a question just doing flush before switch to 8250 so we won't 
loose anything? (and then again why Linux doesn't have such issue 
considering that they have the similar way of work, even without 
virtualization)
> Therefore, if Xen is going to use the 8250 driver after early printk, I
> think the early console should use the same 8250 MMIO path, as Linux does
> with 8250 earlycon. This keeps the early-console backend consistent with
> the driver that takes ownership of the UART and allows Xen to wait for
> UART_LSR_TEMT before reinitialization.
At some point, yes, but then we could lose support for other UARTs that 
OpenSBI could provide out of the box for initial bring-up debugging.
Also, we could have both implementations for early printk (SBI-based and 
MMIO-based), configurable through some option, and allow the user to 
choose which approach to use. But for now, I think we could live with 
the SBI-based implementation (even with support only for old SBI console 
call for a while), as it is more generic, until we actually face a 
performance issue where the MMIO-based approach would start to provide a 
benefit.
~ Oleksii