Re: [PATCH v6] acpi/virt: suppress UART device & SPCR when guest has no serial hardware

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Feb 05, 2026 at 05:15:17PM +0000, Peter Maydell wrote:
> On Thu, 5 Feb 2026 at 10:13, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Feb 05, 2026 at 10:08:32AM +0000, Peter Maydell wrote:
> > > On Thu, 11 Dec 2025 at 10:21, Li Chen <me@linux.beauty> wrote:
> > > >
> > > > From: Li Chen <chenl311@chinatelecom.cn>
> > > >
> > > > 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é <philmd@linaro.org>
> > > > Signed-off-by: Li Chen <chenl311@chinatelecom.cn>
> > > > Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
> > >
> > > 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