From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: xen/arm: Crash when allocating memory for ACPI
 table (Was Re: Design doc of adding ACPI support for arm64 on Xen - version
 2)
Date: Fri, 14 Aug 2015 15:41:36 +0100
Message-ID: <55CDFE20.3070208@citrix.com>
References: <55C413D5.7000709@huawei.com>	<55CAF41C.1090208@huawei.com>
	<55CB0DC0.4020304@citrix.com>	<55CDF5A3.8050201@linaro.org>
	<55CDF87C.40103@citrix.com> <55CDFCBD.608@linaro.org>
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: <55CDFCBD.608@linaro.org>
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 <shannon.zhao@linaro.org>, Shannon Zhao <zhaoshenglong@huawei.com>, xen-devel <xen-devel@lists.xen.org>, Jan Beulich <jbeulich@suse.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Parth Dixit <parth.dixit@linaro.org>, Christoffer Dall <christoffer.dall@linaro.org>
Cc: Hangaohuai <hangaohuai@huawei.com>, "Huangpeng (Peter)" <peter.huangpeng@huawei.com>
List-Id: xen-devel@lists.xenproject.org

On 14/08/15 15:35, Shannon Zhao wrote:
>>>> Do you copy data in the newly allocated memory between 2 xzalloc_bytes?
>>>>
>>>
>>> No, I just use xzalloc_bytes to allocate some place and copy ACPI to the
>>> allocated place, modify the content, then call
>>> raw_copy_to_guest_flush_dcache to copy the modified tables to guest
>>> memory.
>>
>> Can you provide the code and show which call is crashing?
>>
> Oh, sorry. The code is not on hand as it stays at my working computer.
> From previous debug, it fails at the xzalloc_bytes. Because I add two
> printk before and after the xzalloc_bytes, only the before one shows.
> 
> The code calling route is like below:
> 
> acpi_create_fadt();
> acpi_create_gtdt();
> acpi_create_madt();
> acpi_create_stao();
> acpi_create_xsdt();
> acpi_map_rsdp();
> acpi_map_rest_table();
> acpi_create_est();
> acpi_create_mmap();
> ...
> 
> Within everyone of these functions, it will call xzalloc_bytes to
> allocate memory and call raw_copy_to_guest_flush_dcache to copy the
> modified tables to guest memory. And this failure happened at
> acpi_create_xsdt().

When I asked if you copy data between 2 calls of xzalloc_bytes you said
no ... But here you say the invert ... So do you copy data between two
call or not? (FIY, raw_copy_to_guest_flush_dcache is copying data).

> 
> If I add xzalloc_bytes(1000) before acpi_create_xsdt() like below:
> 
> acpi_create_fadt();
> acpi_create_gtdt();
> acpi_create_madt();
> acpi_create_stao();
> 
> xzalloc_bytes(1000);
> 
> acpi_create_xsdt();
> acpi_map_rsdp();
> acpi_map_rest_table();
> acpi_create_est();
> acpi_create_mmap();
> ...
> 
> The failure will not happen at acpi_create_xsdt() but at
> acpi_create_mmap().

Ok, so it's likely a memory corruption. You need to check the bound you
ara using when copying the data to the guest or from the ACPI in
general. Or maybe you just didn't allocate enough space.

Regards,

-- 
Julien Grall