From: Jiang Liu <jiang.liu@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Joerg Roedel <joro@8bytes.org>, Ingo Molnar <mingo@redhat.com>,
hpa@zytor.com, x86@kernel.org, Borislav Petkov <bp@alien8.de>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH 0/5] Fix Intel IRQ remapping initialization order
Date: Tue, 16 Dec 2014 09:45:14 +0800 [thread overview]
Message-ID: <548F8EAA.80700@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1412152012000.17382@nanos>
On 2014/12/16 3:54, Thomas Gleixner wrote:
> On Mon, 15 Dec 2014, Jiang Liu wrote:
>> On 2014/12/15 23:13, Joerg Roedel wrote:
>>> Hi,
>>>
>>> here is a patch-set against tip/x86/apic to fix an initialization order
>>> problem with the IRQ remapping code. The problem is in the ordering of
>>> the irq_remapping_prepare and irq_remapping_supported functions.
>>>
>>> Currently the call-order is irq_remapping_prepare ->
>>> irq_remapping_supported, so that 'prepare' can succeed but 'supported'
>>> fails, so that interrupt remapping gets initialized but not enabled.
>>> This causes a broken interrupt setup on affected systems (machines with
>>> an Intel IOMMU without, or broken, IRQ remapping support). The result
>>> are lost interrupts and a non-bootable system.
>>>
>>> Both functions do checks whether IRQ remapping can be enabled on the
>>> machine. The reason for this is that some checks rely on
>>> dmar_table_init() and thus have to be done in irq_remapping_prepare().
>>>
>>> This patch-set moves all these checks into the irq_remapping_prepare()
>>> path with the right ordering and removes the irq_remapping_supported()
>>> function and its call-backs. This fixes the initializion order problem
>>> and simplifies the exported API from the IOMMU code.
>>>
>>> Please review.
>> Hi Joerg,
>> I have posted a patch set for the same purpose at:
>> https://lkml.org/lkml/2014/12/10/20
>> Seems we need to combine these two patch sets:)
>
> Actually you want to combine it also with these patches:
>
> 326c2bb2c526: iommu/vt-d: Convert allocations to GFP_KERNEL
> e9220e591375: iommu/vt-d: Move iommu preparatory allocations to irq_remap_ops.prepare
> e88edbd316ea: iommu, x86: Restructure setup of the irq remapping feature
> dd60143c04f2: x86, smpboot: Remove pointless preempt_disable() in native_smp_prepare_cpus()
>
> against 3.19 independent of the irqdomain stuff.
>
> So that would be a clean base to put the rest of the irqdomain and
> hotplug stuff on top.
>
> So the ordering of the patches for 3.20 would become:
>
> iommu cleanup (init and allocations)
> acpi cleanup and parser extensions
> ioapic hotplug
> irqdomain conversion
>
> I will route dd60143c04f2 "x86, smpboot: Remove pointless
> preempt_disable() in native_smp_prepare_cpus()" into -rc1. I'm going
> to do so for a few other cherry-picks from x86/apic.
>
> So can you please create a combined series, which just deals with the
> init cleanup and the allocation conversion (ATOMIC -> GFP) based on
> current Linus tree should be fine.
Hi Thomas,
I will work on that, hope we will have something after Christmas Holiday:)
Regards!
Gerry
>
> Thanks,
>
> tglx
>
prev parent reply other threads:[~2014-12-16 1:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 15:13 [PATCH 0/5] Fix Intel IRQ remapping initialization order Joerg Roedel
2014-12-15 15:13 ` [PATCH 1/5] iommu/vt-d: Allocate IRQ remapping data structures only for all IOMMUs Joerg Roedel
2014-12-15 15:13 ` [PATCH 2/5] iommu/vt-d: Don't check for ecap_ir_support in intel_irq_remapping_supported Joerg Roedel
2014-12-15 15:13 ` [PATCH 3/5] iommu/vt-d: Move supported-checks to intel_prepare_irq_remapping() Joerg Roedel
2014-12-15 15:13 ` [PATCH 4/5] iommu/amd: Check for irq-remap support amd_iommu_prepare() Joerg Roedel
2014-12-15 15:13 ` [PATCH 5/5] iommu, x86, apic: Remove irq_remapping_supported() Joerg Roedel
2014-12-15 15:30 ` [PATCH 0/5] Fix Intel IRQ remapping initialization order Jiang Liu
2014-12-15 19:54 ` Thomas Gleixner
2014-12-16 1:45 ` Jiang Liu [this message]
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=548F8EAA.80700@linux.intel.com \
--to=jiang.liu@linux.intel.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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