From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shannon Zhao Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 3 Date: Tue, 18 Aug 2015 17:34:47 +0800 Message-ID: <55D2FC37.4000303@huawei.com> References: <55CE0247.4030805@linaro.org> <55D21AE2020000780009B6D4@prv-mh.provo.novell.com> <55D2A982.9000907@huawei.com> <55D2CD5A02000078000D6BD8@prv-mh.provo.novell.com> <55D2E03E.2060207@huawei.com> <55D305A9020000780009B942@prv-mh.provo.novell.com> <55D2EAFF.20600@huawei.com> <55D312FE020000780009B9A1@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55D312FE020000780009B9A1@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , shannon.zhao@linaro.org Cc: hangaohuai@huawei.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew@fubar.geek.nz, peter.huangpeng@huawei.com, julien.grall@citrix.com, stefano.stabellini@citrix.com, david.vrabel@citrix.com, boris.ostrovsky@oracle.com, xen-devel@lists.xen.org, parth.dixit@linaro.org, christoffer.dall@linaro.org List-Id: xen-devel@lists.xenproject.org On 2015/8/18 17:11, Jan Beulich wrote: >>>> On 18.08.15 at 10:21, wrote: > >> >> On 2015/8/18 16:15, Jan Beulich wrote: >>>>>> On 18.08.15 at 09:35, wrote: >>>> Hi Jan, >>>> >>>> On 2015/8/18 13:14, Jan Beulich wrote: >>>>>>>> Shannon Zhao 08/18/15 5:46 AM >>> >>>>>> On 2015/8/17 23:33, Jan Beulich wrote: >>>>>>>>>> On 14.08.15 at 16:59, wrote: >>>>>>>> 1. Copy and change some EFI and ACPI tables >>>>>>>> ------------------------------------------- >>>>>>> >>>>>>> While some explanation on the reasons for this was given in the past >>>>>>> discussion, I'm still missing a word on the "why" for each of these here. >>>>>>> >>>>>>>> a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor, >>>>>>>> VendorGuid, VendorTable, ConfigurationTable. These changes are not very >>>>>>>> special and it just assign values to these members. >>>>>>> >>>>>>> I continue to question the need for fiddling with this table, not the >>>>>>> least because I don't see how you intend to hand it to the Dom0 >>>>>>> kernel: Are you expecting to call the kernel's ordinary EFI entry >>>>>>> point, despite it not itself running on EFI firmware? >>>>>>> >>>>>> Dom0 gets UEFI info from the minimal DT when booting with UEFI. >>>>>> And the main purpose to create a EFI_SYSTEM_TABLE is to provide the ACPI >>>>>> table root (RSDP) address to Dom0, so it could find the ACPI table. >>>>> >>>>> For that passing the configuration table would suffice. The more that Julien >>>>> in his reply said you're not even intending to use the kernel's EFI stub. >>>> I.e. >>>>> the question remains: How would you expect to hand the System Table >>>>> pointer to Dom0? >>>>> >> >> The System Table pointer will be passed to Dom0 through the minimal DT >> property "linux,uefi-system-table". > > And this is a requirement for Linux? I.e. it can't do with just the > Configuration Table (which architecturally would be more clean imo)? > IIUC, this is a requirement for Linux. Because when Linux parses the minimal DT, it uses below dt_params to match the DT properties. If it doesn't match any of them, it will fial. See efi_get_fdt_params in drivers/firmware/efi/efi.c. static __initdata struct { const char name[32]; const char propname[32]; int offset; int size; } dt_params[] = { UEFI_PARAM("System Table", "linux,uefi-system-table", system_table), UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap), UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size), UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size), UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver) }; Another choice to pass ACPI root table address is to use the kernel parameter "acpi_rsdp". But it still needs to supply the property "linux,uefi-system-table" in DT to make the EFI driver works. While the value of the "linux,uefi-system-table" could be something invalid, so Dom0 would not use the EFI System table. -- Shannon