Re: [libvirt] [PATCH] qemu: Introduce 16550A serial console model
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