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

[Zhang Zheng <zhangzheng@iscas.ac.cn>]

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.
> 
> 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.

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.

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.

BR

Zhang