Re: [edk2-devel] [PATCH 0/9] ArmVirtPkg: support two PL011 UARTs

["Laszlo Ersek" <lersek@redhat.com>]

On 10/26/23 16:46, Julien Grall wrote:
> Hi,
> 
> On 26/10/2023 15:21, Peter Maydell wrote:
>> On Tue, 10 Oct 2023 at 16:33, Laszlo Ersek <lersek@redhat.com> wrote:
>>> On 10/10/23 09:43, Ard Biesheuvel wrote:
>>>> Thanks for looking into this - a cleanup was overdue here.
>>>>
>>>> I will take a look in more detail later, but one thing that occurred
>>>> to me when reading this overview is that having a separate DEBUG
>>>> serial port would permit us to
>>>>
>>>> a) remove it from the DT
>>>
>>> ... as in, hide it from Linux, I assume?
>>>
>>>> b) add a runtime mapping for it
>>>> c) keep using it after ExitBootServices
>>>>
>>>> This could be useful for debugging issues with the variable store etc.
>>>>
>>>> Not saying this is something to address in this series, but I'd like
>>>> to hear your take on this.
>>>>
>>>
>>> Sounds like a useful feature.
>>>
>>> I see four challenges:
>>>
>>>
>>> (1) We'd have to coordinate it with Peter. If we hide any one of the
>>> serial ports from Linux, that may not be what QEMU intends for Linux to
>>> happen. Linux currently ties getties to all serial ports -- via the
>>> serial* aliases, IIUC. Thus, some "positive identification" in the DT
>>> could be necessary (i.e., that edk2 was welcome to hide that port from
>>> Linux).
>>
>> The potential awkwardness here is that what the guest thinks about
>> the serial ports depends on the ACPI table fragments which QEMU
>> provides. EDK2 would need to edit the table fragment to remove any
>> mention of the second UART if it wanted to hide it from the kernel.
>> I don't know how hard that would be in EDK2.
> 
> I am not sure if it would help EDK2 in this case. But we had a similar
> problem when adding support for ACPI in Xen. It was not trivial to
> remove the UART from the ACPI tables provided by the host. So we ended
> up to introduce the STAO table [1]. This is used to describe which
> device will be hidden to the OS.
> 
> Cheers,
> 
> [1] https://wiki.xenproject.org/images/0/02/Status-override-table.pdf
> 

This is a very interesting document. It states the problem well, but the
solution Xen seems to have chosen is the opposite of QEMU's. The
document states that AML generation is difficult, so simple override
tables such as STAO are preferred. QEMU on the other hand has grown a
full-blown runtime AML generator, plus an "ACPI linker/loader script"
language that allows guest firmware to cross-link and install the "tree
of tables", also updating their checksums (under SeaBIOS), all the while
being completely blind to the actual contents of the tables.

This means that under QEMU, the sole source of "ACPI truth" is QEMU.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110119): https://edk2.groups.io/g/devel/message/110119
Mute This Topic: https://groups.io/mt/101834880/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-