Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1698417 > unrolled thread
| Started by | "Zheng, Lv" <lv.zheng@intel.com> |
|---|---|
| First post | 2017-07-28 04:00 +0200 |
| Last post | 2017-07-28 04:30 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier "Zheng, Lv" <lv.zheng@intel.com> - 2017-07-28 04:00 +0200
Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-07-28 04:30 +0200
| From | "Zheng, Lv" <lv.zheng@intel.com> |
|---|---|
| Date | 2017-07-28 04:00 +0200 |
| Subject | RE: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier |
| Message-ID | <u82Jj-5zi-5@gated-at.bofh.it> |
Hi,
> From: Dou Liyang [mailto:douly.fnst@cn.fujitsu.com]
> Sent: Tuesday, July 18, 2017 5:44 PM
> Subject: Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier
>
> Hi Baoquan,
>
> At 07/18/2017 04:45 PM, bhe@redhat.com wrote:
> > On 07/18/17 at 02:08pm, Dou Liyang wrote:
> >> 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.
> >
> > That's because acpi_put_table() will make the table pointer be NULL,
> > while dmar_table_init() will skip parse_dmar_table() calling if
> > dmar_table_initialized is set to 1 in intel_prepare_irq_remapping().
> >
>
> Correctly.
>
> I have considered and removed the *dmar_table_initialized* in this
> situation. So, dmar_table_init() didn't skip parse_dmar_table()
> calling.
>
> I didn't dig into the cause, I think it is interesting, I will do it
> right now and share with you later.
>
> > Dmar hardware support interrupt remapping and io remapping separately. But
> > intel_iommu_init() is called later than intel_prepare_irq_remapping().
> > So what if make dmar_table_init() a reentrant function? You can just
> > have a try, but maybe not a good idea, the dmar table will be parsed
> > twice.
>
> Yes, It is precisely one reason that I gave up invoking
> acpi_put_table().
Parsing a table twice is not a problem on x86.
If you check the code, there are many examples.
It's actually required if you want to use a table both in early stage and late stage.
Thanks
>
> Thanks,
>
> dou.
>
> >
> >>
> >>
> >> Thanks,
> >>
> >> dou.
> >>>
> >>> Thanks
> >>> Lv
> >>>
> >>>> From: Dou Liyang [mailto:douly.fnst@cn.fujitsu.com]
> >>>> Sent: Friday, July 14, 2017 1:53 PM
> >>>> To: x86@kernel.org; linux-kernel@vger.kernel.org
> >>>> Cc: tglx@linutronix.de; mingo@kernel.org; hpa@zytor.com; ebiederm@xmission.com; bhe@redhat.com;
> >>>> peterz@infradead.org; izumi.taku@jp.fujitsu.com; tokunaga.keiich@jp.fujitsu.com; Dou Liyang
> >>>> <douly.fnst@cn.fujitsu.com>; linux-acpi@vger.kernel.org; Rafael J. Wysocki <rjw@rjwysocki.net>;
> Zheng,
> >>>> Lv <lv.zheng@intel.com>; Julian Wollrath <jwollrath@web.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@intel.com>
> >>>> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
> >>>> Cc: linux-acpi@vger.kernel.org
> >>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> >>>> Cc: Zheng, Lv <lv.zheng@intel.com>
> >>>> Cc: Julian Wollrath <jwollrath@web.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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
[toc] | [next] | [standalone]
| From | Dou Liyang <douly.fnst@cn.fujitsu.com> |
|---|---|
| Date | 2017-07-28 04:30 +0200 |
| Message-ID | <u83cm-650-7@gated-at.bofh.it> |
| In reply to | #1698417 |
Hi, Zheng
At 07/28/2017 09:53 AM, Zheng, Lv wrote:
[...]
>>
>>> Dmar hardware support interrupt remapping and io remapping separately. But
>>> intel_iommu_init() is called later than intel_prepare_irq_remapping().
>>> So what if make dmar_table_init() a reentrant function? You can just
>>> have a try, but maybe not a good idea, the dmar table will be parsed
>>> twice.
>>
>> Yes, It is precisely one reason that I gave up invoking
>> acpi_put_table().
>
> Parsing a table twice is not a problem on x86.
> If you check the code, there are many examples.
> It's actually required if you want to use a table both in early stage and late stage.
>
I am sorry I don't explain clearly.
Yeah, in current kernel, The DMAR table has been parsed twice as well.
one is in detect_intel_iommu(), the other is in dmar_table_init().
Here we focus on the reentrant dmar_table_init(), this func contains
many callback for parsing different DMAR type structures, such as DRHD,
RMRR.
acpi_put_table() can release the mapped DMAR address, but we should
clear the remapping structure types manually. and I think parsing these
DMAR type structures again may have an influence on interrupt remapping.
Thanks,
dou.
> Thanks
>
>>
>> Thanks,
>>
>> dou.
>>
>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> dou.
>>>>>
>>>>> Thanks
>>>>> Lv
>>>>>
>>>>>> From: Dou Liyang [mailto:douly.fnst@cn.fujitsu.com]
>>>>>> Sent: Friday, July 14, 2017 1:53 PM
>>>>>> To: x86@kernel.org; linux-kernel@vger.kernel.org
>>>>>> Cc: tglx@linutronix.de; mingo@kernel.org; hpa@zytor.com; ebiederm@xmission.com; bhe@redhat.com;
>>>>>> peterz@infradead.org; izumi.taku@jp.fujitsu.com; tokunaga.keiich@jp.fujitsu.com; Dou Liyang
>>>>>> <douly.fnst@cn.fujitsu.com>; linux-acpi@vger.kernel.org; Rafael J. Wysocki <rjw@rjwysocki.net>;
>> Zheng,
>>>>>> Lv <lv.zheng@intel.com>; Julian Wollrath <jwollrath@web.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@intel.com>
>>>>>> Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
>>>>>> Cc: linux-acpi@vger.kernel.org
>>>>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>>>>>> Cc: Zheng, Lv <lv.zheng@intel.com>
>>>>>> Cc: Julian Wollrath <jwollrath@web.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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web