Re: Design doc of adding ACPI support for arm64 on Xen - version 5

[Shannon Zhao <shannon.zhao@linaro.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