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

[Laszlo Ersek <lersek@redhat.com>]

On 03/01/19 16:09, Peter Maydell wrote:
> On Fri, 1 Mar 2019 at 14: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.
> 
> I would suggest that it probably is not safe. Certainly it
> does not seem likely to be robust against all possible future
> changes to the kernel's driver and/or the firmware's driver.
> 
>> 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.
> 
> Yes, that's basically it (I forget the exact details and it's the
> kind of thing that may well depend on exactly what version of the
> kernel or what version of the firmware you were using). I do still
> have a todo list item to add a 2nd UART (probably "if the user
> specifically asked for it with an extra -serial option"), but
> we can't just add it to the board by default.

Thanks for the info!

> Note that if you are using QEMU under emulation where it is emulating
> EL3 then you always get a second UART which is visible only to the
> secure world. This is specifically intended for firmware to use.

The ArmVirtQemu firmware doesn't handle the secure world at all (yet?).

Thanks
Laszlo