All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiang Liu <jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.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
> 

WARNING: multiple messages have this Message-ID (diff)
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
> 

  reply	other threads:[~2014-12-16  1:45 UTC|newest]

Thread overview: 18+ 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 ` Joerg Roedel
     [not found] ` <1418656404-28575-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
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     ` 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     ` 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     ` 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     ` Joerg Roedel
2014-12-15 15:13   ` [PATCH 5/5] iommu, x86, apic: Remove irq_remapping_supported() Joerg Roedel
2014-12-15 15:13     ` Joerg Roedel
2014-12-15 15:30   ` [PATCH 0/5] Fix Intel IRQ remapping initialization order Jiang Liu
2014-12-15 15:30     ` Jiang Liu
     [not found]     ` <548EFE88.3000307-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2014-12-15 19:54       ` Thomas Gleixner
2014-12-15 19:54         ` Thomas Gleixner
2014-12-16  1:45         ` Jiang Liu [this message]
2014-12-16  1:45           ` Jiang Liu

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-vuqaysv1563yd54fqh9/ca@public.gmane.org \
    --cc=bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org \
    --cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    --cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.