Re: [RFC 0/3] Enable runtime serial debug for ArmVirtQemu

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Fri, 1 Mar 2019 at 15:59, Laszlo Ersek <lersek@redhat.com> wrote:
>
> +Peter
>
> On 03/01/19 13:24, Heyi Guo wrote:
> > On 2019/2/28 21:39, Laszlo Ersek wrote:
>
> >> (4) What's most worrying is that this change would lead to an unexpected
> >> sharing of the PL011 device between the OS and the firmware. I don't
> >> think that's a great idea, especially if QEMU's ACPI payload explicitly
> >> advertises the port to the OS.
> > That's true, so I propose to disable the feature by default. It is only
> > used for UEFI runtime code debug. It is always painful when we don't a
> > handy debug tool for runtime services code.
>
> I think this is the only problem that we have at the design level.
>
> What I'd like to understand is whether it is safe to drive the PL011
> serial port from both the firmware and the kernel. Consider a situation
> where one VCPU in the guest executes a runtime service call, and writes
> to PL011 from firmware code. Meanwhile a different VCPU in the guest
> executes some kernel code that produces a log message directly on the
> serial console. (Because, I don't think that a runtime service call on
> one CPU stops the world for *all* CPUs, in the Linux kernel.) For
> starters, the serial output could be garbled, as a consequence, but will
> the PL011 register state be messed up irrevocably as well? I don't know.
>

This is fundamentally broken. The OS will drive the PL011 in interrupt
mode, while the firmware will poll the FIFO registers directly.

> This is why I'm not a big fan of this approach. Using separate devices
> for kernel and firmware would be a lot better.
>

+1

> I remember that Peter did some work to enable two PL011 devices on the
> "virt" board. IIRC the issue was that the PL011 enumeration order /
> numbering in edk2, and in the Linux (guest) kernel, was exactly the
> opposite. And that caused both logs to go to different devices; you
> couldn't have a single log file that started with the firmware log, and
> continued (after a definite switch-over) with the kernel log.
>
> But in this case, where the firmware could produce log messages on
> serial during OS runtime, that's actually the setup I would recommend. A
> clean separation between the serial devices used by the firmware and the OS.
>
> The rest of the issues in this series should be more simple to clean up
> (rework some commit messages, remove stale code etc).
>
> Thanks
> Laszlo