On Thu, Feb 05, 2026 at 05:15:17PM +0000, Peter Maydell wrote: > 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
that is why we have machine versioning? I would say -nodefaults really should not have a serial port unless defined, no? -- MST
