From: Xunlei Pang <xlpang@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, Baoquan He <bhe@redhat.com>
Subject: Re: [PATCH] iommu/vt-d: Assign old irt entries a common valid vector in kdump kernel
Date: Thu, 3 Mar 2016 11:29:14 +0800 [thread overview]
Message-ID: <56D7AF8A.7080008@redhat.com> (raw)
In-Reply-To: <20160302145823.GV22747@8bytes.org>
On 03/02/2016 at 10:58 PM, Joerg Roedel wrote:
> On Wed, Mar 02, 2016 at 06:02:28PM +0800, Xunlei Pang wrote:
>> Currently, the kernel copies the old irt entries during iommu
>> initialization for kdump, so old vectors in the first kernel are
>> used but having no related kernel irq handlers set explicitly,
>> this can lead to some problems after lapics are enabled:
>> - When some in-flight dma finished and triggered an interrupt,
>> the kernel will throw a warning message in do_IRQ() like "No
>> irq handler", because handle_irq() will return false with no
>> irq_desc handlers. This may confuse users.
>> - When the in-flight dma interrupt arrives, and if there happens
>> to be an irq with the same vector allocated in kdump kernel,
>> it will invoke the existing ISR registered in kdump kernel as
>> if one valid interrupt in the kdump kernel happens. This might
>> cause some wrong software logic, for example if the ISR always
>> wakes up a process.
> Hmm, the current situation with misdirected irq messages in the kdump
> kernel is not different from a situation without any iommu at all,
> right?
Right, non-iommu in-flight DMA after crash also suffers from this.
I think both of them should be fixed if possible.
> And the goal of preserving the old mappings is to get as close as
> possible to the situation without iommu. This seems to carry the VT-d
> driver away from that.
Without iommu, it's not so easy to fix due to the MSI registers
located in different pci devices. But vt-d introduces a mechanism
to redirect both MSI/MSI-X and I/O APIC to a common IR table,
so we can handle that much easily with the help of the IR table.
On kdump side, present-day servers with vt-d enabled are
becoming increasingly common-place, if this does happen in
real world(usually it will), that would be hard to dig it out, so I
think it would be better if we can fix it.
Also CC kexec list
Regards,
Xunlei
>
>
> Joerg
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Xunlei Pang <xlpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] iommu/vt-d: Assign old irt entries a common valid vector in kdump kernel
Date: Thu, 3 Mar 2016 11:29:14 +0800 [thread overview]
Message-ID: <56D7AF8A.7080008@redhat.com> (raw)
In-Reply-To: <20160302145823.GV22747-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On 03/02/2016 at 10:58 PM, Joerg Roedel wrote:
> On Wed, Mar 02, 2016 at 06:02:28PM +0800, Xunlei Pang wrote:
>> Currently, the kernel copies the old irt entries during iommu
>> initialization for kdump, so old vectors in the first kernel are
>> used but having no related kernel irq handlers set explicitly,
>> this can lead to some problems after lapics are enabled:
>> - When some in-flight dma finished and triggered an interrupt,
>> the kernel will throw a warning message in do_IRQ() like "No
>> irq handler", because handle_irq() will return false with no
>> irq_desc handlers. This may confuse users.
>> - When the in-flight dma interrupt arrives, and if there happens
>> to be an irq with the same vector allocated in kdump kernel,
>> it will invoke the existing ISR registered in kdump kernel as
>> if one valid interrupt in the kdump kernel happens. This might
>> cause some wrong software logic, for example if the ISR always
>> wakes up a process.
> Hmm, the current situation with misdirected irq messages in the kdump
> kernel is not different from a situation without any iommu at all,
> right?
Right, non-iommu in-flight DMA after crash also suffers from this.
I think both of them should be fixed if possible.
> And the goal of preserving the old mappings is to get as close as
> possible to the situation without iommu. This seems to carry the VT-d
> driver away from that.
Without iommu, it's not so easy to fix due to the MSI registers
located in different pci devices. But vt-d introduces a mechanism
to redirect both MSI/MSI-X and I/O APIC to a common IR table,
so we can handle that much easily with the help of the IR table.
On kdump side, present-day servers with vt-d enabled are
becoming increasingly common-place, if this does happen in
real world(usually it will), that would be hard to dig it out, so I
think it would be better if we can fix it.
Also CC kexec list
Regards,
Xunlei
>
>
> Joerg
>
WARNING: multiple messages have this Message-ID (diff)
From: Xunlei Pang <xlpang@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Baoquan He <bhe@redhat.com>,
kexec@lists.infradead.org
Subject: Re: [PATCH] iommu/vt-d: Assign old irt entries a common valid vector in kdump kernel
Date: Thu, 3 Mar 2016 11:29:14 +0800 [thread overview]
Message-ID: <56D7AF8A.7080008@redhat.com> (raw)
In-Reply-To: <20160302145823.GV22747@8bytes.org>
On 03/02/2016 at 10:58 PM, Joerg Roedel wrote:
> On Wed, Mar 02, 2016 at 06:02:28PM +0800, Xunlei Pang wrote:
>> Currently, the kernel copies the old irt entries during iommu
>> initialization for kdump, so old vectors in the first kernel are
>> used but having no related kernel irq handlers set explicitly,
>> this can lead to some problems after lapics are enabled:
>> - When some in-flight dma finished and triggered an interrupt,
>> the kernel will throw a warning message in do_IRQ() like "No
>> irq handler", because handle_irq() will return false with no
>> irq_desc handlers. This may confuse users.
>> - When the in-flight dma interrupt arrives, and if there happens
>> to be an irq with the same vector allocated in kdump kernel,
>> it will invoke the existing ISR registered in kdump kernel as
>> if one valid interrupt in the kdump kernel happens. This might
>> cause some wrong software logic, for example if the ISR always
>> wakes up a process.
> Hmm, the current situation with misdirected irq messages in the kdump
> kernel is not different from a situation without any iommu at all,
> right?
Right, non-iommu in-flight DMA after crash also suffers from this.
I think both of them should be fixed if possible.
> And the goal of preserving the old mappings is to get as close as
> possible to the situation without iommu. This seems to carry the VT-d
> driver away from that.
Without iommu, it's not so easy to fix due to the MSI registers
located in different pci devices. But vt-d introduces a mechanism
to redirect both MSI/MSI-X and I/O APIC to a common IR table,
so we can handle that much easily with the help of the IR table.
On kdump side, present-day servers with vt-d enabled are
becoming increasingly common-place, if this does happen in
real world(usually it will), that would be hard to dig it out, so I
think it would be better if we can fix it.
Also CC kexec list
Regards,
Xunlei
>
>
> Joerg
>
next prev parent reply other threads:[~2016-03-03 3:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 10:02 [PATCH] iommu/vt-d: Assign old irt entries a common valid vector in kdump kernel Xunlei Pang
2016-03-02 10:02 ` Xunlei Pang
[not found] ` <1456912948-5052-1-git-send-email-xlpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-02 14:58 ` Joerg Roedel
2016-03-02 14:58 ` Joerg Roedel
2016-03-03 3:29 ` Xunlei Pang [this message]
2016-03-03 3:29 ` Xunlei Pang
2016-03-03 3:29 ` Xunlei Pang
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=56D7AF8A.7080008@redhat.com \
--to=xlpang@redhat.com \
--cc=bhe@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.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 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.