linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dou Liyang <douly.fnst@cn.fujitsu.com>
To: "bhe@redhat.com" <bhe@redhat.com>
Cc: "Zheng, Lv" <lv.zheng@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"izumi.taku@jp.fujitsu.com" <izumi.taku@jp.fujitsu.com>,
	"tokunaga.keiich@jp.fujitsu.com" <tokunaga.keiich@jp.fujitsu.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Julian Wollrath <jwollrath@web.de>
Subject: Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier
Date: Tue, 18 Jul 2017 17:44:19 +0800	[thread overview]
Message-ID: <0c13e0de-9a37-2992-ef00-20b6ad67dbc5@cn.fujitsu.com> (raw)
In-Reply-To: <20170718084521.GC2344@x1>

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().

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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

  reply	other threads:[~2017-07-18  9:44 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14  5:52 [PATCH v7 00/13] Unify the interrupt delivery mode and do its setup in advance Dou Liyang
2017-07-14  5:52 ` [PATCH v7 01/13] x86/apic: Construct a selector for the interrupt delivery mode Dou Liyang
2017-07-14  5:52 ` [PATCH v7 02/13] x86/apic: Prepare for unifying the interrupt delivery modes setup Dou Liyang
2017-07-14  5:52 ` [PATCH v7 03/13] x86/apic: Split local APIC timer setup from the APIC setup Dou Liyang
2017-07-14  5:52 ` [PATCH v7 04/13] x86/apic: Move logical APIC ID away from apic_bsp_setup() Dou Liyang
2017-07-14  5:52 ` [PATCH v7 05/13] x86/apic: Unify interrupt mode setup for SMP-capable system Dou Liyang
2017-07-14  5:52 ` [PATCH v7 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup Dou Liyang
2017-07-14  5:52 ` [PATCH v7 07/13] x86/apic: Unify interrupt mode setup for UP system Dou Liyang
2017-07-14  5:52 ` [PATCH v7 08/13] x86/ioapic: Refactor the delay logic in timer_irq_works() Dou Liyang
2017-07-14  5:52 ` [PATCH v7 09/13] x86/init: add intr_mode_init to x86_init_ops Dou Liyang
2017-07-14  5:52 ` [PATCH v7 10/13] x86/xen: Bypass intr mode setup in enlighten_pv system Dou Liyang
2017-07-14  5:52 ` [PATCH v7 11/13] x86/time: Initialize interrupt mode behind timer init Dou Liyang
2017-07-14  5:52 ` [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier Dou Liyang
2017-07-18  5:18   ` Zheng, Lv
2017-07-18  6:08     ` Dou Liyang
2017-07-18  8:45       ` bhe
2017-07-18  9:44         ` Dou Liyang [this message]
2017-07-28  1:53           ` Zheng, Lv
2017-07-28  2:28             ` Dou Liyang
2017-07-26 12:19         ` Dou Liyang
2017-07-27  6:08           ` bhe
2017-07-27  6:29             ` Dou Liyang
2017-07-31 11:20             ` Dou Liyang
2017-07-31 13:30               ` bhe
2017-07-31 10:50   ` Dou Liyang
2017-08-24  3:54     ` Dou Liyang
2017-08-24  8:05       ` Baoquan He
2017-08-24  9:28         ` Dou Liyang
2017-08-24 10:21           ` Baoquan He
2017-08-24 10:44             ` Dou Liyang
2017-08-24 16:38       ` Rafael J. Wysocki
2017-08-25  2:06         ` Dou Liyang
2017-08-25 12:27           ` Rafael J. Wysocki
2017-08-25 14:09             ` Dou Liyang
2017-07-14  5:52 ` [PATCH v7 13/13] x86/apic: Remove the init_bsp_APIC() Dou Liyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c13e0de-9a37-2992-ef00-20b6ad67dbc5@cn.fujitsu.com \
    --to=douly.fnst@cn.fujitsu.com \
    --cc=bhe@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=jwollrath@web.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=tokunaga.keiich@jp.fujitsu.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).