|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 34/35] arm : acpi workarounds for firmware/linux dependencies
Hi Parth, On 05/02/2015 22:59, Julien Grall wrote: +#ifdef CONFIG_X86 #define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1)) +#else +#define is_xmalloc_memory(ptr) 1 +#endifWhy? I though this was resolved?i am not aware what was the resolution on it? So, I took time to understand better the issue. This is happening at the first call of acpi_tb_resize_root_table_list (see stack trace at the end of the mail). We are trying to allocate ACPI_MAX_TABLES * sizeof (struct acpi_table_desc).The size of the structure is 32 bytes which give a total allocation of 4096 bytes on both x86 and ARM64. Why it's working on x86? This big allocation is done via the boot allocator memory (because the system state is early boot). Hopefully, we never have to resize it. On ARM64, ACPI is initialized after the boot allocator has ended, so we have to use xmalloc which will return a page-align pointer. As ACPI on ARM64 will never use the boot allocator, maybe the xmalloc_is_ptr is acceptable? It would require a big explanation which it's safe. What do you think? [<0000000000284bfc>] acpi_os_zalloc_memory+0x5c/0x8c (PC) [<0000000000284be8>] acpi_os_zalloc_memory+0x48/0x8c (LR) [<000000000028571c>] acpi_tb_resize_root_table_list+0x94/0x124 [<00000000002857d0>] acpi_allocate_root_table+0x24/0x2c [<0000000000285800>] acpi_initialize_tables+0x28/0x98 [<000000000028663c>] acpi_table_init+0x1c/0x88 [<000000000028bcbc>] acpi_boot_table_init+0x1c/0x48 [<0000000000289d08>] start_xen+0x574/0xcbc [<0000000000200610>] paging+0x88/0xc0 Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |