Re: [Qemu-devel] [PATCH 3/3] hw/arm/virt-acpi-build: Add second UART to ACPI tables

[Andrew Jones]

On Tue, Dec 12, 2017 at 01:56:44PM +0000, Ard Biesheuvel wrote:
> On 12 December 2017 at 13:28, Laszlo Ersek <address@hidden> wrote:
> > On 12/12/17 13:47, Peter Maydell wrote:
> >> On 12 December 2017 at 12:41, Laszlo Ersek <address@hidden> wrote:
> >>> I agree. There's one user-visible complication: while with one UART,
> >>> it's not possible to mix things up, with two UARTs, users will
> >>> inevitably want to assign inverse roles to them, relative to what QEMU /
> >>> the firmware assigns originally.
> >>>
> >>> E.g. if one PL011 is redirected to a regular file (debug messages) and
> >>> the other one to stdio (console), there will be complaints that "I
> >>> wanted it the other way around". The redirection happens on the backend
> >>> (chardev) level, but the firmware won't see the difference on the
> >>> frontend (PL011) level.
> >>>
> >>> Is it possible to add a new property to the UART nodes in the DTB, like
> >>> "purpose"?
> >>
> >> This is what the "chosen" stdout-path node in the DTB is for,
> >> but you said you didn't want to look at that :-) (it means
> >> "device to be used for boot console output".)
> >
> > :(
> >
> > Ard is right that we really shouldn't do that kind of parsing magic in
> > very early UEFI stuff.
> >
> >
> >>> Or can we make a virt-arm policy that "first -serial is always ...,
> >>> second -serial is always ..."?
> >>
> >> Well, the first -serial will always be the 0x09000000 one
> >> that we have today, and the second -serial will be the other
> >> one (unless you have -machine secure=yes, in which case
> >> second -serial is the secure-only UART and third -serial is
> >> the second NS UART).
> >>
> >> Is this any different to the x86 case, where there are two
> >> UARTs at different IO port/IRQ locations?
> >
> > OVMF (x86) uses two distinct devices for the two purposes discussed.
> >
> > * It uses the "debug console device" for debug message output, at
> > hard-coded IO port 0x402; so if you'd like to capture those messages,
> > then you have to add:
> >
> >   -chardev file,id=debugfile,path=debug.log \
> >   -device isa-debugcon,iobase=0x402,chardev=debugfile \
> >
> > (or the more traditional
> >
> >   -debugcon file:debug.log \
> >   -global isa-debugcon.iobase=0x402 \
> > )
> >
> > * For console I/O, it uses the first serial port. (I think I have once
> > investigated what it takes to use other serial ports for console I/O --
> > I'm no longer sure if "it happens to be impossible in OVMF", or just
> > "nobody ever does that".)
> >
> >
> > The important distinction (on the UEFI level anyway) is that the debug
> > messages need to go to a super dumb device, while console I/O can use a
> > much higher-level serial IO abstraction ("protocol").
> >
> >
> >> I think the only thing users really expect is that if you're
> >> using just the one serial port for anything then it's the
> >> first one.
> >
> > You are right -- we've never had two (non-secure) UARTs on virt-arm, so
> > we can invent whatever assignment, as long as:
> >
> > - the single UART case doesn't break (keeps receiving both debug output
> > and console IO),
> >
> > - whatever we invent for the two UARTs case now, it remains consistent
> > over time. I think this implies we can rely on the FDT node ordering in
> > the firmware (if we want to use the 2nd UART at all, that is), and then
> > QEMU shouldn't change the serial_hds[] <-> FDT node mapping in the
> > future, in machvirt_init() and the callees thereof.
> >
> 
> Given that the DEBUG output is only produced on DEBUG builds, couldn't
> we simply stipulate that DEBUG output appears on the PL011 with the
> lowest physical address? That keeps the current status quo, and is
> probably sufficient for 99% of the use cases of people using the DEBUG
> builds.

I was thinking that if AAVMF learned to use a second UART for debug
output, that the debug builds could go away, as they have for x86 (IIUC).
If a user wires up a second UART, then AAVMF could unconditionally
output debug messages to it. Not wiring it up would lose the messages,
which is no different than the non-verbose build we have today. It
would be nice if could tell AAVMF not to use a second UART for debug
messages too, though, as the debug messages make AAVMF quite slow, and
the user may want to provide the guest a second UART.

> 
> Then, we can introduce some code to decode stdout-path in FdtClientDxe
> (a higher level DT parsing driver) so that the actual serial console
> gets installed onto whichever UART is described as the system console.
> Also, given that ArmVirtQemu is tightly coupled to QEMU/mach-virt, we
> could decide to only use node names in stdout-path (as we do
> currently) to simplify the parsing logic.
>

That sounds reasonable and would only require adding a comment above
the setting of stdout-path in the QEMU code to formalize it.

Thanks,
drew