Re: ACPI/UEFI support for Xen/ARM status?

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.11.2021 20:09, Julien Grall wrote:
> Hi Jan,
> 
> On 15/11/2021 10:13, Jan Beulich wrote:
>> On 12.11.2021 17:02, Julien Grall wrote:
>>> Hi Elliott,
>>>
>>> On 12/11/2021 15:44, Elliott Mitchell wrote:
>>>> On Fri, Nov 12, 2021 at 05:54:08AM +0000, Henry Wang wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of
>>>>>> Elliott Mitchell
>>>>>>
>>>>>> I've been busy with another part of this project, so I've lost track of
>>>>>> progress on ACPI/UEFI support on ARM.
>>>>>>
>>>>>> Last I'd read full support for ACPI/UEFI seemed a ways off.  Using a stub
>>>>>> domain to constrain ACPI table parsing seemed the favored approach.  I
>>>>>> was under the impression that would take some time.
>>>>>>
>>>>>> What is the status?  Do the Xen/ARM leads have any guesses for when full
>>>>>> ACPI/UEFI support might reach completion?
>>>>>
>>>>> I am doing some development based on the Xen UEFI/ACPI on AArch64 using
>>>>> the Arm FVP_Base platform. Using edk2 and master branch of Xen with
>>>>> `CONFIG_ACPI=y`, it seems everything can work properly.
>>>>>
>>>>> Here are some of my logs:
>>>>> Shell> FS2:EFI\XEN\xen.efi
>>>>> Xen 4.16-rc (c/s Fri Nov 12 02:34:01 2021 +0000 git:323b47ffd9-dirty) EFI 
>>>>> loader
>>>>> ...
>>>>> (XEN) PFN compression on bits 20...22
>>>>> (XEN) ACPI: RSDP F5E30018, 0024 (r2 LINARO)
>>>>> (XEN) ACPI: XSDT F5E3FE98, 005C (r1 LINARO RTSMVEV8        2       
>>>>> 1000013)
>>>>> (XEN) ACPI: FACP F5E3FA98, 0114 (r6 LINARO RTSMVEV8        2 LNRO        
>>>>> 2)
>>>>> (XEN) ACPI: DSDT F5E3ED98, 02AB (r2 LINARO RTSMVEV8        4 INTL 
>>>>> 20200925)
>>>>> (XEN) ACPI: GTDT F5E3FC18, 00E0 (r2 LINARO RTSMVEV8        2 LNRO        
>>>>> 2)
>>>>> (XEN) ACPI: APIC F5E3E998, 02D4 (r4 LINARO RTSMVEV8        2 LNRO        
>>>>> 2)
>>>>> (XEN) ACPI: SPCR F5E3FF98, 0050 (r2 LINARO RTSMVEV8        2 LNRO        
>>>>> 2)
>>>>> (XEN) Domain heap initialised
>>>>
>>>>> ...
>>>>> [    0.000000] ACPI: SPCR 0x00000000F5E3FF98 000050 (v02 LINARO RTSMVEV8 
>>>>> 00000002 LNRO 00000002)
>>>>> [    0.000000] ACPI: SPCR: console: pl011,mmio32,0x1c090000,115200
>>>>> ...
>>>>>
>>>>> Hopefully this answers your question. :)
>>>>
>>>> Thanks for the attempt at answering, but the SPCR entry tells me there is
>>>> a substantial portion of ACPI/UEFI functionality you're not testing.  I'm
>>>> specifically looking for framebuffer console support and SPCR says you're
>>>> using serial console.  While serial console is appropriate for true
>>>> servers, for some use cases it is inadequate.
>>>
>>> We don't have any support for framebuffer in Xen on Arm (even for
>>> Device-Tree). I would be happy to consider any patches if you are plan
>>> to post some.
>>>
>>>>
>>>> Julien Grall and Stefano Stabellini had been proposing doing ACPI table
>>>> parsing in a stub domain, but I'm unaware of the status.  Not finding
>>>> much suggests it hasn't gone very far yet.
>>>
>>> This was a very early proposal in case we needed to parse the DSDT in
>>> Xen. This hasn't been needed so far, hence why this is not implemented
>>> and no-one worked on it.
>>>
>>> I am not very familiar how the framebuffer is detected in ACPI. Can you
>>> provide more details on what exactly you want to parse?
>>
>> I don't think there's any ACPI support involved there. Instead UEFI data
>> needs propagating to Dom0, as that can't access EFI boot services itself.
>> At least this is all that's needed on the x86 side (and all the needed
>> code is there, just presumably not [fully] wired up on Arm).
> 
> Thanks for the feedback. At the moment, we don't enable EFI runtime 
> services nor propagate it to Dom0. So this needs to be wired up.

Well, the frame buffer info doesn't really get communicated via a
hypercall, but rather via start_info. Albeit for PVH my proposal to
reuse that wasn't accepted, and I'm still waiting for an alternative
proposal by either Roger or Andrew. IOW I don't know yet how this
will be done on PVH.

> However, for Elliott's case, I am not sure this is going to sufficient. 
> The Raspberry PI has some devices that can only DMA into the first 1GB 
> of the RAM (the GPU seems to be one). So we need to make sure Xen is 
> allocating enough memory for Dom0 below that limit.

Urgh.

> Do you have similar problem on x86? If so, how do you deal with it?

No, we don't have any such restrictions that I would be aware of.

Jan