Hi Michael and Igor, ---- On Wed, 04 Feb 2026 00:27:06 +0800 Michael S. Tsirkin <[email protected]> wrote --- > On Thu, Dec 18, 2025 at 04:12:53PM +0100, Igor Mammedov wrote: > > On Fri, 12 Dec 2025 10:01:08 +0800 > > Li Chen <[email protected]> wrote: > > > > > Hi Michael, > > > > > > ---- On Thu, 11 Dec 2025 21:10:18 +0800 Michael S. Tsirkin > > > <[email protected]> wrote --- > > > > On Thu, Dec 11, 2025 at 06:20:25PM +0800, Li Chen 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]> > > > > > > > > This bothers me: > > > > won't this mean number of serial devices changes silently? So for > > > > example, if you install a guest, see that 1st serial device is broken, > > > > configure it with 2nd one as a work around, now with your change there > > > > is no second one so guest will be broken? > > > > > > > > > > > > I seems safer to have compat machinery around and avoid > > > > changing this for old machine types. > > > > > > Thanks for pointing this out, you’re right that changing the number of > > > serial > > > devices that the guest sees is risky for existing machine types. > > > > > > For v7 I’m planning to take a more conservative approach and only gate > > > SPCR > > > on the presence of a backend for the primary UART, while keeping the > > > ACPI > > > UART devices in DSDT unchanged. > > > Concretely: > > > - virt ACPI DSDT will continue to unconditionally describe the UART(s) > > > as before, > > > so the guest-visible UART topology doesn’t change for existing virt-* > > > machines. > > > - We only call spcr_setup() when there is a backend attached to UART0 > > > (e.g. serial_hd(0) != NULL), > > > so SPCR doesn’t point at a completely unusable console when the user > > > passes -serial none. > > > > > > In particular, for a command line like -serial none -serial pty, this > > > means SPCR would not be present > > > (rather than silently switching it to UART1/pty). My reasoning is that, > > > for existing virt machines, > > > SPCR is meant to describe “the board’s primary console (UART0)”, not > > > “the first UART that happens > > > to have a host backend”, and changing that interpretation feels like it > > > would need compat machinery > > > and a new machine type. > > > > > > The qtests already force -serial null for the UEFI-based virt tests, so > > > they will still exercise the SPCR path. > > > > > > Would this behaviour be acceptable for you, or would you prefer that I > > > go further and also add a compat > > > flag/new machine type where SPCR can follow “the first UART with a > > > backend” while old virt-* machines > > > keep the current UART/SPCR semantics? > > > > > > all described above looks complicated. > > In ACPI tables we usually try to avoid compat settings, and do them only > > if we have to. > > > > So question is how guest enumerates serial ports when > > '-nodefaults' is used _and_ there is a second serial port configured > > (is it even possible?) > > check it with and without you patch please, to see what difference the > > patch makes. > > > > > > > > Regards, > > > Li > > > > > Looks like this got stuck. I think what Igor and me are saying is, do > not rush to do compat, just test what happens and document. If guests > survive fine, then it's fine. > >
Sorry this got stuck. I just tested the scenario Igor asked about (guest serial enumeration with -nodefaults and a second -serial backend) on aarch64 virt + UEFI, both with and without my v6 patch. Without the patch, -nodefaults -serial none still produces a DSDT with COM0 and an SPCR table, and `-nodefaults backend is indeed possible). With the v6 patch, both command lines end up with no COMx nodes in DSDT and no SPCR because the DSDT UART nodes were gated on serial_hd(0). This means v6 silently changes the guest-visible UART topology and matches Michael’s concern about guests configured to use the 2nd serial device as a workaround. So, for v7 I will keep the UART devices in DSDT unchanged, and only gate SPCR on serial_hd(0) != NULL, so SPCR never points at a completely unusable console. Please let me know if I missed anything. Regards, Li
