+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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
