[libvirt] [PATCH] qemu: Introduce 16550A serial console model

[Andrea Bolognani]

On Mon, 2018-08-27 at 15:31 +0100, Richard W.M. Jones wrote:
> On Mon, Aug 27, 2018 at 02:10:18PM +0200, Andrea Bolognani wrote:
> > None of the existing models is suitable for use with
> > RISC-V virt guests, and we don't want information about
> > the serial console to be missing from the XML.
> > 
> > The name is based on comments in qemu/hw/riscv/virt.c:
> > 
> >   RISC-V machine with 16550a UART and VirtIO MMIO
> > 
> > and in qemu/hw/char/serial.c:
> > 
> >   QEMU 16550A UART emulation
> > 
> > along with the output of dmesg in the guest:
> > 
> >   Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> >   10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
> >     base_baud= 230400) is a 16550A
> 
> FWIW on the real hardware:
> 
> [    4.078734] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [    4.084078] 10010000.serial: ttySI0 at MMIO 0x10010000 (irq = 43, base_baud = 0) is a sifive-serial
> [    4.751449] 10011000.serial: ttySI1 at MMIO 0x10011000 (irq = 44, base_baud = 0) is a sifive-serial

Well, that's a SiFive machine so sifive-serial doesn't look out
of place. I believe the sifive_* machine types in QEMU will also
expose a sifive-serial rather than a 16550a, though I haven't
actually verified that's the case.

> Now about the patch ...
> 
> I think this is fine provided it doesn't bake in future libvirt API
> that we'll regret.

The very idea behind this patch is that spelling out defaults
in the XML leaves the door open to changing them down the line
without affecting existing guests or breaking migration :)

> However the real story is that what real RISC-V hardware will look
> like is undecided.  For embedded they're making all the same mistakes
> as ARMv7 all over again (despite our clear warnings).  So expect
> wildly different implementations, no way to probe at runtime, random
> device trees, crazy board descriptions littering the kernel and qemu,
> out of tree drivers, etc.  All that crap.
> 
> For servers there's a working group supposedly looking into this and
> going to produce an SBSA/SBBR-style specification.  Last time I looked
> it was a single page with no detail, and I can't actually find the
> link to that right now.  In any case it's nowhere near decided.  It
> would be nice if they standardized a 16550A UART at a known address,
> PCIe, etc. but at the moment I wouldn't make plans based on sanity
> prevailing.

Well that's disappointing :( I guess they'll have to get to
a reasonable place the long way around, just like Arm did.

> TL;DR: Patch is fine as long as we can change things later without
> maintaining ABI.

Good to hear! Thanks for the feedback :)

-- 
Andrea Bolognani / Red Hat / Virtualization