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
+#endif
Why? I though this was resolved?
i am not aware what was the resolution on it?
I didn't have access on my IRC log in the plane. So I wasn't able to
find the discussion.
AFAIR, this issue was because we are allocating a chunk bigger than
PAGE_SIZE in acpi_tb_resize_root_table_list.
x86 manage to never allocate a chunk bigger than PAGE_SIZE. So I'm not
sure why ARM64 requires too. This would need more debug.
This macro is used to know if the memory has been allocated by the boot
allocator of the memory pool.
So 2 solutions:
1) We find a better way to use detect it
2) We avoid to allocate big chunk
I'm not sure which one is the easiest/better one.
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@lists.xen.org
http://lists.xen.org/xen-devel