[PATCH v2 0/3] hw/arm: Create second NonSecure UART for virt board

Peter Maydell posted 3 patches 4 months, 2 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20240610162343.2131524-1-peter.maydell@linaro.org
Maintainers: Peter Maydell <peter.maydell@linaro.org>, Shannon Zhao <shannon.zhaosl@gmail.com>, "Michael S. Tsirkin" <mst@redhat.com>, Igor Mammedov <imammedo@redhat.com>, Ani Sinha <anisinha@redhat.com>
docs/system/arm/virt.rst |  6 ++++-
include/hw/arm/virt.h    |  5 ++--
hw/arm/virt-acpi-build.c | 22 ++++++++++-------
hw/arm/virt.c            | 52 +++++++++++++++++++++++++++++++++-------
4 files changed, 65 insertions(+), 20 deletions(-)
[PATCH v2 0/3] hw/arm: Create second NonSecure UART for virt board
Posted by Peter Maydell 4 months, 2 weeks ago
This is v2 of a series I posted back in October last year:
 https://patchew.org/QEMU/20231023161532.2729084-1-peter.maydell@linaro.org/
At the time I wanted to wait until EDK2 had been updated so it
didn't behave weirdly in the presence of a second UART. That
happened at the tail end of last year, but I'd forgotten that
we never committed the QEMU side of things until Laszlo kindly
reminded me a few days ago. So there are now no blockers to
getting this patchset into QEMU.


For some use-cases, it is helpful to have more than one UART available
to the guest, but the Arm 'virt' board only creates one.  If the
second UART slot is not already used for a TrustZone Secure-World-only
UART, create it as a NonSecure UART if the user provides a serial
backend for it (e.g. via a second -serial command line option).

We've wanted this for literally years; my first attempt at it
was this series in 2017:
https://lore.kernel.org/all/1512745328-5109-1-git-send-email-peter.maydell@linaro.org/
More recently Axel Heider revived the idea with a patchset in 2022:
https://lore.kernel.org/qemu-devel/166990501232.22022.16582561244534011083-0@git.sr.ht/

However it has previously foundered on the problem that EDK2 does
odd things when presented with multiple UARTs in the DTB. (Specifically,
it will send the guest GRUB bootloader output to UART1, debug output
to both UARTs 0 and 1 depending on how far through boot it is, and the
guest kernel will use UART0 since that's what the ACPI tables say.)

Several things here I think mean we can finally get over this issue:
 * I learnt about the device tree "aliases" node; this allows us to
   explicitly say "this node is the first UART and this node is the
   second UART". So guests like Linux that follow this part of the
   DTB spec will always get the UART order correct; and if there are
   obscure guests that turn out to misbehave, we can point at the
   spec and say "this is how you should fix this on your end"...
 * This patch, like Axel's patch, only creates the second UART if
   the user asks for it on the command line, so any pre-existing
   command lines will not change behaviour.
 * Laszlo Ersek has kindly written some EDK2 patches that rationalise
   what it does when it finds more than one UART. This means that
   we can tell any users who do want to use two UARTs with EDK2
   "you should upgrade your EDK2 blobs to version NNN if you want to
   do that". These are now in a released EDK2 and QEMU's EDK2
   blobs have been updated to a version including these changes.

Changes since v2:
 * rebased (the search-n-replace patch 2 needed some minor tweaks)
 * updated commit message to patch 3 with details of which EDK2
   release you need for second-uart support

Patches 1 and 2 have been reviewed; patch 3 needs review.

thanks
-- PMM

Peter Maydell (3):
  hw/arm/virt: Add serial aliases in DTB
  hw/arm/virt: Rename VIRT_UART and VIRT_SECURE_UART to VIRT_UART[01]
  hw/arm/virt: allow creation of a second NonSecure UART

 docs/system/arm/virt.rst |  6 ++++-
 include/hw/arm/virt.h    |  5 ++--
 hw/arm/virt-acpi-build.c | 22 ++++++++++-------
 hw/arm/virt.c            | 52 +++++++++++++++++++++++++++++++++-------
 4 files changed, 65 insertions(+), 20 deletions(-)

-- 
2.34.1