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: Wed, 26 Jul 2017 20:19:22 +0800	[thread overview]
Message-ID: <2855c940-9e57-f06f-d9f0-dc5eb4408b37@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().
>
> 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.

The true reason why the kernel panic is that acpi_put_table() only
released DMAR table structure, but not released the remapping
structures in DMAR table, such as DRHD, RMRR. So the address of
RMRR parsed in early ACPI stage will be used in late ACPI stage in
intel_iommu_init(), which make the kernel panic.

The solution is invoking the intel_iommu_free_dmars() before
dmar_table_init() in intel_iommu_init() to release the RMRR.
Demo code will show at the bottom.

I prefer to invoke acpi_early_init() earlier. But it needs a regression
test[1].

I am looking for Thinkpad x121e (AMD E-450 APU) to test. I have tested
it in Thinkpad s430, It's OK.

BTY, I am confused how does the ACPI subsystem affect PIT which
will be used to fast calibrate CPU frequency[2].

Do you have any idea?

[1] https://lkml.org/lkml/2014/3/10/123
[2] https://lkml.org/lkml/2014/3/12/3


  drivers/iommu/dmar.c                | 27 +++++++++++----------------
  drivers/iommu/intel-iommu.c         |  2 ++
  drivers/iommu/intel_irq_remapping.c | 17 ++++++++++++++++-
  include/linux/dmar.h                |  2 ++
  init/main.c                         |  2 +-
  5 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index c8b0329..e6261b7 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -68,6 +68,8 @@ DECLARE_RWSEM(dmar_global_lock);
  LIST_HEAD(dmar_drhd_units);

  struct acpi_table_header * __initdata dmar_tbl;
+struct acpi_table_header * __initdata dmar_tbl_original;
+
  static int dmar_dev_scope_status = 1;
  static unsigned long dmar_seq_ids[BITS_TO_LONGS(DMAR_UNITS_SUPPORTED)];

@@ -627,6 +629,7 @@ parse_dmar_table(void)
  	 * fixed map.
  	 */
  	dmar_table_detect();
+	dmar_tbl_original = dmar_tbl;

  	/*
  	 * ACPI tables may not be DMA protected by tboot, so use DMAR copy
@@ -811,26 +814,18 @@ int __init dmar_dev_scope_init(void)

  int __init dmar_table_init(void)
  {
-	static int dmar_table_initialized;
  	int ret;

-	if (dmar_table_initialized == 0) {
-		ret = parse_dmar_table();
-		if (ret < 0) {
-			if (ret != -ENODEV)
-				pr_info("Parse DMAR table failure.\n");
-		} else  if (list_empty(&dmar_drhd_units)) {
-			pr_info("No DMAR devices found\n");
-			ret = -ENODEV;
-		}
-
-		if (ret < 0)
-			dmar_table_initialized = ret;
-		else
-			dmar_table_initialized = 1;
+	ret = parse_dmar_table();
+	if (ret < 0) {
+		if (ret != -ENODEV)
+			pr_info("Parse DMAR table failure.\n");
+	} else  if (list_empty(&dmar_drhd_units)) {
+		pr_info("No DMAR devices found\n");
+		ret = -ENODEV;
  	}

-	return dmar_table_initialized < 0 ? dmar_table_initialized : 0;
+	return ret;
  }

  static void warn_invalid_dmar(u64 addr, const char *message)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 687f18f..90f74f4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4832,6 +4832,8 @@ int __init intel_iommu_init(void)
  	}

  	down_write(&dmar_global_lock);
+
+	intel_iommu_free_dmars();
  	if (dmar_table_init()) {
  		if (force_on)
  			panic("tboot: Failed to initialize DMAR table\n");
diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index a5b89f6..ccaacda 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -675,7 +675,7 @@ static void __init intel_cleanup_irq_remapping(void)
  		pr_warn("Failed to enable irq remapping. You are vulnerable to 
irq-injection attacks.\n");
  }

-static int __init intel_prepare_irq_remapping(void)
+static int __init __intel_prepare_irq_remapping(void)
  {
  	struct dmar_drhd_unit *drhd;
  	struct intel_iommu *iommu;
@@ -743,6 +743,21 @@ static int __init intel_prepare_irq_remapping(void)
  	return -ENODEV;
  }

+static int __init intel_prepare_irq_remapping(void)
+{
+	int ret;
+
+	ret = __intel_prepare_irq_remapping();
+
+	if (dmar_tbl_original) {
+		acpi_put_table(dmar_tbl_original);
+		dmar_tbl_original = NULL;
+		dmar_tbl = NULL;
+	}
+
+	return ret;
+}
+
  /*
   * Set Posted-Interrupts capability.
   */
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index e8ffba1..987b076 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -50,6 +50,8 @@ struct dmar_dev_scope {

  #ifdef CONFIG_DMAR_TABLE
  extern struct acpi_table_header *dmar_tbl;
+extern struct acpi_table_header *dmar_tbl_original;
+
  struct dmar_drhd_unit {
  	struct list_head list;		/* list of drhd units	*/
  	struct  acpi_dmar_header *hdr;	/* ACPI header		*/
diff --git a/init/main.c b/init/main.c
index 52dee20..052481f 100644
--- a/init/main.c
+++ b/init/main.c
@@ -655,12 +655,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();

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

  parent reply	other threads:[~2017-07-26 12:19 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
2017-07-28  1:53           ` Zheng, Lv
2017-07-28  2:28             ` Dou Liyang
2017-07-26 12:19         ` Dou Liyang [this message]
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=2855c940-9e57-f06f-d9f0-dc5eb4408b37@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).