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. > > thanks > -- PMM
presumably, things would be different with -nodefaults?
