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

[Shannon Zhao <zhaoshenglong@xxxxxxxxxx>]

Hi Julien,

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.

> 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?
Actually I have the same worries before when I handle the RTC device
problem between UEFI and QEMU. You can see the conversation from below urls.

http://permalink.gmane.org/gmane.comp.bios.edk2.devel/6474
https://lists.gnu.org/archive/html/qemu-arm/2016-01/msg00132.html

Thanks,
-- 
Shannon


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