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 02:31:05PM +0000, Ard Biesheuvel wrote:
> On 12 December 2017 at 14:17, Peter Maydell <address@hidden> wrote:
> > On 12 December 2017 at 14:16, Ard Biesheuvel <address@hidden> wrote:
> >> On 12 December 2017 at 14:13, Peter Maydell <address@hidden> wrote:
> >>> On 12 December 2017 at 14:12, Ard Biesheuvel <address@hidden> wrote:
> >>>> On 12 December 2017 at 14:10, Peter Maydell <address@hidden> wrote:
> >>>>> That doesn't actually usefully separate debug output from the
> >>>>> console, though, because stdout-path is also going to point
> >>>>> to the UART with the lowest physical address...
> >>>>>
> >>>>
> >>>> By default, yes, just like is currently the case. But I would assume
> >>>> this new serial port could be appointed 'console' and put into
> >>>> stdout-path by QEMU, based on the command line options?
> >>>
> >>> We don't have any command line options for doing that, and I'm
> >>> generally reluctant to introduce new command line UI, especially
> >>> new command line UI that's specific to Arm and not also needed
> >>> for x86.
> >>>
> >>
> >> If stdout-path is always going to point to address@hidden, why would
> >> we need to parse it?
> >
> > If you had always parsed stdout-path, we wouldn't need to worry
> > about the order in which the UART nodes appear in the dtb...
> >
> 
> That's a fair point. But it still does not justify introducing added
> complexity in the firmware, if the conclusion is always going to be
> that the console will be on address@hidden
> 
> To Drew's point re DEBUG builds, I don't think we should generally
> enable DEBUG and send the output to nowhereland if the user does not
> wire it up. That's a MMIO trap and two world switches for each
> character written, if I am not mistaken, and the DEBUG builds are very
> noisy.

100% agree, which is why I said "If a user wires up a second UART...",
but I guess my "Not wiring it up would lose the messages..." sentence
was ambiguous. I didn't mean they'd output to no where, I meant those
messages wouldn't be output. I.e. some sort of debug_printf() function
would be written that only actually does a write when there's a debug
UART on the other end to write to.

I just commented on patch 2/3 of this series asking if we shouldn't
just not allocate the second UART's MMIO region and IRQ, when the user
doesn't provide a '-serial' option for it. If we didn't, then AAVMF
would just not output debug messages when only one UART (the console)
is found in the DT.

Thanks,
drew