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 >
