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? Regards, Li
