Date: Wed, 2 Mar 2016 15:58:23 +0100
From: Joerg Roedel <joro@8bytes.org>
To: Xunlei Pang <xlpang@redhat.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
        Baoquan He <bhe@redhat.com>, ZhenHua Li <zhen-hual@hp.com>
Subject: Re: [PATCH] iommu/vt-d: Assign old irt entries a common valid vector
 in kdump kernel
Message-ID: <20160302145823.GV22747@8bytes.org>
References: <1456912948-5052-1-git-send-email-xlpang@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1456912948-5052-1-git-send-email-xlpang@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1238
Lines: 26

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?

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.


	Joerg