On Thu, 5 Feb 2026 at 10:13, Michael S. Tsirkin <[email protected]> wrote: > > On Thu, Feb 05, 2026 at 10:08:32AM +0000, Peter Maydell wrote: > > On Thu, 11 Dec 2025 at 10:21, Li Chen <[email protected]> wrote: > > > > > > From: Li Chen <[email protected]> > > > > > > virt machines always instantiate a PL011/16550 UART at slot 0 and describe > > > it in ACPI (DSDT and optional SPCR table). When the command line disables > > > the serial backend (e.g. "-serial none"), the guest still sees the UART as > > > a preferred console even though it is not usable. > > > > > > Teach the virt ACPI code to omit the UART device and SPCR when there is no > > > serial backend attached. This matches the hardware that the guest can > > > actually use and avoids confusing firmware or OS code that relies on SPCR. > > > > > > The bios-tables-test qtests rely on an ACPI UART node and SPCR entry for > > > UEFI-based virt machines. To keep those tests working we create a UART > > > with a "null" chardev backend instead. This preserves the ACPI tables > > > while discarding the firmware's serial output so it does not corrupt the > > > TAP stdout stream. > > > > > > Suggested-by: Philippe Mathieu-Daudé <[email protected]> > > > Signed-off-by: Li Chen <[email protected]> > > > Reviewed-by: Sunil V L <[email protected]> > > > > Sorry, I must have missed this patch previously. I'm not sure that > > this is a good idea, because it means: > > * the dtb version of virt and the ACPI handling diverge > > * we tangle up "what chardev do you want to connect serial output to" > > and "what UARTs does the guest see" > > > > If the user explicitly sends the first serial port output > > to nowhere with "-serial none -serial stdio" they presumably > > had a reason for that and won't be happy to find that we've > > adjusted the ACPI tables to redirect that output to the > > second serial port they were planning to use for something else.
> presumably, things would be different with -nodefaults? -nodefaults doesn't generally do much on Arm boards, because we don't have a lot of "pluggable thing that's plugged in by default" that we would turn off -- that's more of an x86 thing. On the virt board the UART situation is a bit complicated, for command-line backwards compatibility reasons: * the first UART always exists * if you're emulating the security extensions, the second UART always exists (and is the secure-world UART) * otherwise, the second UART exists only if the user configured a second serial backend (i.e. provided "-serial foo -serial bar" or similar) If I were designing it again from scratch without the back-compat baggage, it would probably have three always-exists UARTs, one for secure-world and two for normal-world. thanks -- PMM
