On 12/12/17 13:07, Peter Maydell wrote: > On 12 December 2017 at 11:59, Laszlo Ersek <ler...@redhat.com> wrote: >> Peter, what is the intended use of the second UART? > > Per the commit message: > # there are some > # use cases where having a second UART would be useful (like > # bare-metal testing where you don't really want to have to > # probe and set up a PCI device just to have a second comms > # channel). > > From QEMU's point of view this is just "some people would like > more than one UART, x86 provides more than one UART, it's > easy to provide an extra UART and it's up to the guest what > it would like to do with it". If there's utility for the > OVMF firmware in having 2 UARTs that's doubly good reason > to have it.
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"? Or can we make a virt-arm policy that "first -serial is always ..., second -serial is always ..."? ( Technically the latter could work, because: - QEMU_OPTION_serial / add_device_config() keeps the command line order, - the traversal of DEV_SERIAL with serial_parse() also keeps that order, - machvirt_init() uses the same order via serial_hds[] - create_uart() always prepends the new node to the DTB, via qemu_fdt_add_subnode() (if I understood Ard right). I'm not sure though whether libvirt would like the ordering of -serial options to carry any meaning. ) Sorry if these questions don't belong on the QEMU level. Thanks Laszlo
