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 5 Date: Tue, 1 Sep 2015 20:35:03 +0800 Message-ID: <55E59B77.2090905@huawei.com> References: <55E02DC5.4090202@huawei.com> <55E05A2F.1090305@citrix.com> <55E1042C.6000308@linaro.org> <55E43E36.90108@citrix.com> <55E4428C.7020308@huawei.com> <55E449DA.6080309@citrix.com> <55E525A8.3010302@huawei.com> <55E58BC7.7090403@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E58BC7.7090403@citrix.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: Julien Grall , Shannon Zhao , xen-devel , Christoffer Dall , Ian Campbell , Stefano Stabellini , Stefano Stabellini , Jan Beulich , Parth Dixit , andrew@fubar.geek.nz, Boris Ostrovsky , David Vrabel , Roger Pau Monne Cc: Hangaohuai , "Huangpeng (Peter)" List-Id: xen-devel@lists.xenproject.org On 2015/9/1 19:28, Julien Grall wrote: > Hi Shannon, > On 01/09/15 05:12, Shannon Zhao wrote: >> I tried this. Directly use the "kinfo->gnttab_start = __pa(_stext)" as >> the address where these tables are mapped to Dom0. But the value of >> gnttab_start is lower than the start of RAM, so Dom0 ingore these >> regions and boot failed. see early_init_dt_add_memory_arch() > > Can you elaborate? How Linux will fail? If this region is marked as > reserved in the UEFI memory map, Linux will mark the memory as reserved. > > Furthermore, *ioremap is used in order to map the EFI tables so I don't > see a reason to fail. > It's fine to parse EFI table but fails to parse ACPI table. It doesn't add the memblock since it doesn't pass below check in early_init_dt_add_memory_arch: if (base + size < phys_offset) { pr_warning("Ignoring memory block 0x%llx - 0x%llx\n", base, base + size); return; } It's due to kinfo->gnttab_start (e.g. 0x87e00000) lower than the memory start address (e.g. 0x90000000). Then Linux will fail at parsing ACPI table. ACPI: Interpreter enabled ACPI: Using GIC for interrupt routing Unhandled fault: alignment fault (0x96000021) at 0xffffff8000068184 Internal error: : 96000021 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6+ #143 Hardware name: (null) (DT) task: ffffffc008870000 ti: ffffffc00884c000 task.ti: ffffffc00884c000 PC is at acpi_get_phys_id+0x264/0x290 LR is at acpi_get_phys_id+0x178/0x290 >>>> >>>> In addition, how does UEFI find the space to place the tables? Could we >>>> use the same way? >>> >>> I think that those tables are living in the RAM and region used are >>> marked as reserved. >>> >> >> So can we use the same way for Dom0? I think the Linux will reserve the >> regions for EFI in reserve_regions(). Therefore, Dom0 will not use these >> reserved regions for other use. > > Jan had some concerned about putting the EFI tables in RAM owned by DOM0 > (see [1]). > > Can you explain how Linux behave with EFI tables. I.e: > - Where tables are expected to live (RAM, others...)? I'm not sure about this. > - Are thoses regions freed at some point to be re-use? I look at how Linux reserve these regions. See it in reserve_regions() (arch/arm64/kernel/efi.c). It uses memblock_add() to add them to global memblock and then uses memblock_reserve() to reserve them (like allocating some memory) for certain use (here we use them to store the tables). And I didn't see other places call memblock_free() to free them. -- Shannon