Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751564AbdGRJot (ORCPT ); Tue, 18 Jul 2017 05:44:49 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:42448 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751349AbdGRJoX (ORCPT ); Tue, 18 Jul 2017 05:44:23 -0400 X-IronPort-AV: E=Sophos;i="5.22,518,1449504000"; d="scan'208";a="21445470" Subject: Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier To: "bhe@redhat.com" References: <1500011554-9784-1-git-send-email-douly.fnst@cn.fujitsu.com> <1500011554-9784-13-git-send-email-douly.fnst@cn.fujitsu.com> <1AE640813FDE7649BE1B193DEA596E886CEE2130@SHSMSX101.ccr.corp.intel.com> <20170718084521.GC2344@x1> CC: "Zheng, Lv" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "mingo@kernel.org" , "hpa@zytor.com" , "ebiederm@xmission.com" , "peterz@infradead.org" , "izumi.taku@jp.fujitsu.com" , "tokunaga.keiich@jp.fujitsu.com" , "linux-acpi@vger.kernel.org" , "Rafael J. Wysocki" , Julian Wollrath From: Dou Liyang Message-ID: <0c13e0de-9a37-2992-ef00-20b6ad67dbc5@cn.fujitsu.com> Date: Tue, 18 Jul 2017 17:44:19 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170718084521.GC2344@x1> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 212734D14A76.A6FC0 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4399 Lines: 145 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 >>>> ; linux-acpi@vger.kernel.org; Rafael J. Wysocki ; Zheng, >>>> Lv ; Julian Wollrath >>>> 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 >>>> Signed-off-by: Dou Liyang >>>> Cc: linux-acpi@vger.kernel.org >>>> Cc: Rafael J. Wysocki >>>> Cc: Zheng, Lv >>>> Cc: Julian Wollrath >>>> --- >>>> 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 >>>> >>>> >>> >>> >>> >>> >> >> > > >