[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d0ce9178-4b06-081b-6b12-a8cd1c5352b7@cn.fujitsu.com>
Date: Tue, 18 Jul 2017 14:08:05 +0800
From: Dou Liyang <douly.fnst@...fujitsu.com>
To: "Zheng, Lv" <lv.zheng@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...nel.org" <mingo@...nel.org>,
"hpa@...or.com" <hpa@...or.com>,
"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
"bhe@...hat.com" <bhe@...hat.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"izumi.taku@...fujitsu.com" <izumi.taku@...fujitsu.com>,
"tokunaga.keiich@...fujitsu.com" <tokunaga.keiich@...fujitsu.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Julian Wollrath <jwollrath@....de>
Subject: Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization
earlier
Hi, Zheng
At 07/18/2017 01:18 PM, Zheng, Lv wrote:
> Hi,
>
> Can the problem be fixed by invoking acpi_put_table() for mapped DMAR table?
Invoking acpi_put_table() is my first choice. But it made the kernel
*panic* when we try to get the table again in intel_iommu_init() in
late stage.
I am also confused that:
There are two places where we used DMAR table in Linux:
1) In detect_intel_iommu() in ACPI early stage:
...
status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
....
if (dmar_tbl) {
acpi_put_table(dmar_tbl);
dmar_tbl = NULL;
}
2) In dmar_table_init() in ACPI late stage:
...
status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
...
As we know, dmar_table_init() is called by intel_iommu_init() and
intel_prepare_irq_remapping().
When I invoked acpi_put_table() in the intel_prepare_irq_remapping() in
early stage like 1) shows, kernel will panic.
Thanks,
dou.
>
> Thanks
> Lv
>
>> From: Dou Liyang [mailto:douly.fnst@...fujitsu.com]
>> Sent: Friday, July 14, 2017 1:53 PM
>> To: x86@...nel.org; linux-kernel@...r.kernel.org
>> Cc: tglx@...utronix.de; mingo@...nel.org; hpa@...or.com; ebiederm@...ssion.com; bhe@...hat.com;
>> peterz@...radead.org; izumi.taku@...fujitsu.com; tokunaga.keiich@...fujitsu.com; Dou Liyang
>> <douly.fnst@...fujitsu.com>; linux-acpi@...r.kernel.org; Rafael J. Wysocki <rjw@...ysocki.net>; Zheng,
>> Lv <lv.zheng@...el.com>; Julian Wollrath <jwollrath@....de>
>> Subject: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier
>>
>> Linux uses acpi_early_init() to put the ACPI table management into
>> the late stage from the early stage where the mapped ACPI tables is
>> temporary and should be unmapped.
>>
>> But, now initializing interrupt delivery mode should map and parse the
>> DMAR table earlier in the early stage. This causes an ACPI error when
>> Linux reallocates the ACPI root tables. Because Linux doesn't unmapped
>> the DMAR table after using in the early stage.
>>
>> Invoke acpi_early_init() earlier before late_time_init(), Keep the DMAR
>> be mapped and parsed in late stage like before.
>>
>> Reported-by: Xiaolong Ye <xiaolong.ye@...el.com>
>> Signed-off-by: Dou Liyang <douly.fnst@...fujitsu.com>
>> Cc: linux-acpi@...r.kernel.org
>> Cc: Rafael J. Wysocki <rjw@...ysocki.net>
>> Cc: Zheng, Lv <lv.zheng@...el.com>
>> Cc: Julian Wollrath <jwollrath@....de>
>> ---
>> Test in my own PC(Lenovo M4340).
>> Ask help for doing regression testing for the bug said in commit c4e1acbb35e4
>> ("ACPI / init: Invoke early ACPI initialization later").
>>
>> init/main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/init/main.c b/init/main.c
>> index df58a41..7a09467 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -654,12 +654,12 @@ asmlinkage __visible void __init start_kernel(void)
>> kmemleak_init();
>> setup_per_cpu_pageset();
>> numa_policy_init();
>> + acpi_early_init();
>> if (late_time_init)
>> late_time_init();
>> calibrate_delay();
>> pidmap_init();
>> anon_vma_init();
>> - acpi_early_init();
>> #ifdef CONFIG_X86
>> if (efi_enabled(EFI_RUNTIME_SERVICES))
>> efi_enter_virtual_mode();
>> --
>> 2.5.5
>>
>>
>
>
>
>
Powered by blists - more mailing lists