|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 3/3] drivers/char: Panic when the requested UART fails to initialise
Hi, On 02/09/2026 08:36, Michal Orzel wrote: I just want to emphasize that from functional safety perspective, this is the preferred approach. The user's request is given the priority and whenever it cannot be satisfied, Xen should panic.uart_init() cannot tell its caller that the UART the user asked for did not come up: every failure path only printks. Arm and RISC-V carry on into console_init_preirq() and boot without a console, rather than refusing to boot as they do elsewhere when a user request cannot be met. Return an error from dt_uart_init() and panic in start_xen(). An explicit request Xen cannot satisfy should stop the boot rather than silently degrade it, If there is a silent degradation, then we need to document this behavior somewhere. I am happy to keep this documented under docs/fusa. In the safety manual, we should mention all the instances when there is a silent degradation observed, the underlying reason and how the end user can detect it. Other FuSa experts can comment. which is what start_xen() already does for the rest of the boot configuration. Only a path given on the command line counts as a request we have to satisfy. Falling back to /chosen/stdout-path or acpi_uart_init() therefore never fails. SPCR is firmware provided, the analogue of stdout-path, and there is no ACPI equivalent of dtuart= to make an explicit request with. While here, decide whether the SPCR table was found from the returned acpi_status rather than from the table pointer, which was only NULL because the caller initialised it - acpi_get_table() writes it solely on success. Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx> --- With this change diagnosibility decreases only for a single scenario: when dom0 is reachable not via console (e.g. network) and you'd have used xl dmesg to read messages from the conring. On Arm (I suppose RISC-V is similar), given that safety becomes the major use-case and we need to satisfy all the user/guest-xen contracts, I think the patch moves us in a direction we already chose (i.e. we panic on every boot failure where we cannot meet the requests). --- xen/arch/arm/setup.c | 5 +++- xen/arch/riscv/setup.c | 6 ++++- xen/drivers/char/uart-init.c | 52 +++++++++++++++++++++--------------- xen/include/xen/serial.h | 6 ++++- 4 files changed, 44 insertions(+), 25 deletions(-) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 6310a47d68b6..d0066db42e7c 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -379,7 +379,10 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr)gic_preinit(); - uart_init(); LGTM - Ayan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |