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

[Laszlo Ersek <lersek@redhat.com>]

+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 why I'm not a big fan of this approach. Using separate devices
for kernel and firmware would be a lot better.

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