Re: [PATCH] hw/arm/virt: Second uart for normal-world

[Peter Maydell]

On Mon, 9 Dec 2019 at 15:25, Daniel Thompson <address@hidden> wrote:
>
> The virt machine can have two UARTs but the second UART is only
> registered when secure-mode support is enabled. Change the machine so
> this UART is always registered bringing the behaviour of the virt
> machine closer to x86 land, where VMs can be expected to support two
> UARTs. This approach is also similar to how a TZPC would typically
> make a UART inaccessible to normal world on physical hardware.
>
> Signed-off-by: Daniel Thompson <address@hidden>
> ---
>
> Notes:
>     It is difficult to add a UART without some kind of odd difference of
>     behaviour somewhere. As far as I could tell the choices are:
>
>     1. Move the secure UART from UART1 to UART2. This is a
>        not-backward-compatible difference of behaviour (will likely break
>        the command lines for existing users of the secure UART).
>
>     2. We tack the new UART on at the end, meaning UART1 will re-enumerates
>        as UART2 when secure mode is enabled/disabled. This is rather
>        surprising for users.
>
>     3. UART1 is registered and inaccessible when secure mode is not enabled
>        (e.g. user must provide a dummy -serial argument to skip the missing
>        UART)
>
>     4. Normal world can only use the second UART if there is no secure mode
>        support.
>
>     5. Don't support an extra UART ;-)
>
>     Of these I concluded that #4 was least worst! Ultimately it is should be
>     unsurprising for users because it is how most physical hardware works
>     (e.g. a trustzone controller is used to make an existing UART
>     inaccessible to normal world).

This change looks simple but it will break booting of UEFI
in the guest. Unfortunately UEFI enumerates UARTs in the guest
in the opposite order to the Linux kernel, so whichever way
round you put the extra UART something will get it wrong and
stop producing output where the user expects.

I think the conclusion I came to was that the only way to
avoid breaking existing command lines would be to only
create the second UART if the user explicitly asked for
it somehow. (Possibly just looking at "if there really is
a 2nd serial on the command line" with "if (serial_hd(1)"
would suffice, or perhaps not.)

You also need to do something to add the 2nd UART to the ACPI tables.

(Very out of date and broken patchset from last time I looked at this:
https://lists.gnu.org/archive/html/qemu-arm/2017-12/msg00063.html
)

thanks
-- PMM