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.
