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: Wed, 02 Sep 2015 20:02:52 +0800 Message-ID: <55E6E56C.80100@linaro.org> 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> <55E59B77.2090905@huawei.com> <55E5AADB.70503@citrix.com> <55E690DC.6000303@huawei.com> <55E6D8EA.4020008@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55E6D8EA.4020008@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 Cc: Hangaohuai , Ian Campbell , Stefano Stabellini , andrew@fubar.geek.nz, "Huangpeng (Peter)" , Stefano Stabellini , David Vrabel , Jan Beulich , Boris Ostrovsky , Parth Dixit , Christoffer Dall , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On 2015/9/2 19:09, Julien Grall wrote: > On 02/09/15 07:02, Shannon Zhao wrote: >> >> >> On 2015/9/1 21:40, Julien Grall wrote: >>> On 01/09/15 13:35, Shannon Zhao wrote: >>>> >>>> >>>> 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 >>> >>> IIRC, this is because Linux will consider the region as non-RAM (see >>> acpi_os_ioremap in arch/arm64/include/asm/acpi.h). >>> >>> IHMO this is not a problem in the design but a bug in Linux/Xen. >>> >>> You need to see how to make Linux see the region as a RAM (either by >>> early_init_dt_add_memory_arch or memblock_reserve). This would mean >>> either change the way you describe the region in the UEFI memory map or >>> fix Linux. >>> >> There are some descriptions in Documentation/arm64/booting.txt of Linux: >> >> "The Image must be placed text_offset bytes from a 2MB aligned base >> address near the start of usable system RAM and called there. Memory >> below that base address is currently unusable by Linux, and therefore it >> is strongly recommended that this location is the start of system RAM. >> At least image_size bytes from the start of the image must be free for >> use by the kernel." >> >> From this, it says "Memory below that base address is currently unusable >> by Linux". So if we put these tables below Dom0 RAM address and even >> describe these regions as RAM, the Linux could not use them. >> >> Any thoughts about this? > > Hold on, this is about Linux able to use the memory for his own usage. > ACPI table are not part of this memory because they are marked reserved > by the firmware. > > If we follow your logic, all ACPI tables always should be above the > kernel. I don't believe this is the case and it would be buggy on Xen > because of the DOM0 direct RAM mapping (i.e the first RAM bank can be > very high and the kernel too). > It looks weird. But from the booting.txt, it says the memory below base address is unusable and from early_init_dt_add_memory_arch in Linux, it really ignores the memblock below the PAGE_OFFSET. > I think the problem is how you reserved this region in the EFI memory > table. From what I saw, you marked this new memory with EFI_MEMORY_WB > (which means that the region can be usable by Linux). > Yes, I mark it with EFI_MEMORY_WB. Is this right? -- Shannon