Re: [PATCH RESEND 03/14] libxc: Add placeholders for ACPI tables blob and size

[Julien Grall <julien.grall@arm.com>]

On 16/06/16 07:53, Shannon Zhao wrote:
> Hi Julien,

Hi Shannon,

>
> On 2016/6/7 21:06, Julien Grall wrote:
>>> That's its own mechanism I think and UEFI wants all the memory maps
>>> under its control. And it's same for QEMU(x86 and ARM) and also for Xen
>>> on x86. You can have a look at the OvmfPkg/AcpiPlatformDxe/Xen.c which
>>> is used for x86 Xen DomU.
>>
>> UEFI cannot control the memory map because it is not capable to know
>> what a region is used for (such as magic pages, grant table...).
>>
>> In the case of domU for x86, the ACPI table are located in predefine
>> physical address by hvmloader.
> The truth is that hvmloader puts the tables at address
> ACPI_PHYSICAL_ADDRESS(0x000EA020), but UEFI will install the tables and
> relocate them as well. You can see OvmfPkg/AcpiPlatformDxe/Xen.c in edk2
> source code.
>
> So I think it's same with ARM except x86 puts the tables at one fixed
> address while ARM dynamically computes the address and passes the
> address information to UEFI through dts.
>
> Yeah, of course we can let ARM put the tables at one fixed address and
> also it doesn't need the ACPI module to pass the address and let UEFI
> find the RSDP table from the fixed address. But what's the difference
> between the fixed and dynamicall ones? Because both ways UEFI will
> install and relocate the tables.

You seem to think that OVMF is the only UEFI implementation available 
and its behavior is set in stone. Can you quote the UEFI spec stating 
the ACPI tables will always be relocated?

If not, putting the ACPI module right in the middle of memory is not the 
wisest choice because the tables can not be easily relocated like other 
modules (DT, Kernel, initramfs).

My suggestion to put the ACPI tables at a static address outside the RAM 
is to let the choice to the firmware to do whatever it wants without 
impacting the performance of a kernel if it ever decides to keep in 
place the tables.

However, this static address is from the toolstack point of view. The 
firmware should not assume any static address because the guest memory 
layout is not part of the ABI for Xen ARM (i.e it can be modified 
between two releases). This is to allow us reshuffling the layout to 
make space for new features.

>
>> I really don't see any reason that would
>> prevent us to do the same on ARM.
>>
>> If the UEFI firmware wants to relocate the tables, then fine. But we
>> should also think about any firmware which may not relocate the tables.
> Can you name one firmware except the UEFI?

Sorry I meant any other UEFI implementation (i.e other than OVMF) may 
not relocate the tables.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel