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

[Julien Grall <julien.grall@xxxxxxx>]

Hello Shannon,

On 16/06/16 11:45, Shannon Zhao wrote:
> > > 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).
> The ACPI tables are put after the DT. How could you say the ACPI is in
> the middle while DT not?
Because the position of the DT in the memory is defined by the Linux 
boot ABI (see section 4.b in Documentation/arm/Booting).
> > 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.
> Sure? Currently for Xen x86, edk2 uses XEN_ACPI_PHYSICAL_ADDRESS to find
> RSDP. If we put the tables at another address, DomU will fail to boot.
I am not sure to follow here. Why do you mention x86 here? My point was 
only for ARM and we are not tight to what x86 does.
> > > > 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.
> So please tell me the name of other UEFI implementation.
What is the point? All our decision should be based on the specification 
and not ONE specific implementation.
Regards,

--
Julien Grall

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