From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: Design doc of adding ACPI support for arm64 on Xen
 - version 5
Date: Tue, 1 Sep 2015 14:40:43 +0100
Message-ID: <55E5AADB.70503@citrix.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>
	<55E59B77.2090905@huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <55E59B77.2090905@huawei.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Shannon Zhao <zhaoshenglong@huawei.com>, Shannon Zhao <shannon.zhao@linaro.org>, xen-devel <xen-devel@lists.xen.org>, Christoffer Dall <christoffer.dall@linaro.org>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, Jan Beulich <jbeulich@suse.com>, Parth Dixit <parth.dixit@linaro.org>, andrew@fubar.geek.nz, Boris Ostrovsky <boris.ostrovsky@oracle.com>, David Vrabel <david.vrabel@citrix.com>, Roger Pau Monne <roger.pau@citrix.com>
Cc: Hangaohuai <hangaohuai@huawei.com>, "Huangpeng (Peter)" <peter.huangpeng@huawei.com>
List-Id: xen-devel@lists.xenproject.org

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.

Regards,

-- 
Julien Grall