[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140310214318.GJ4352@redhat.com>
Date: Mon, 10 Mar 2014 17:43:18 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Bill Sumner <bill.sumner@...com>
Cc: dwmw2@...radead.org, indou.takao@...fujitsu.com, bhe@...hat.com,
joro@...tes.org, linux-pci@...r.kernel.org,
kexec@...ts.infradead.org, alex.williamson@...hat.com,
linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
ddutile@...hat.com, doug.hatch@...com,
ishii.hironobu@...fujitsu.com, bhelgaas@...gle.com, zhenhua@...com
Subject: Re: [PATCHv3 0/6] Crashdump Accepting Active IOMMU
On Fri, Jan 10, 2014 at 03:07:26PM -0700, Bill Sumner wrote:
[..]
> This patch set modifies the behavior of the iommu in the (new) crashdump kernel:
> 1. to accept the iommu hardware in an active state,
> 2. to leave the current translations in-place so that legacy DMA will continue
> using its current buffers until the device drivers in the crashdump kernel
> initialize and initialize their devices,
> 3. to use different portions of the iova address ranges for the device drivers
> in the crashdump kernel than the iova ranges that were in-use at the time
> of the panic.
Conceptually, above makes sense to me. I have few queries.
- Do we need to pass any kind of data from first kernel to second kernel,
like table size etc? Calgary IOMMU was using first kernel's tables
also and it was determining previous kernel's table size using saved_max_pfn.
- I don't know how IOMMU translation tables look like, but are new DMA
zones setup by drivers in second kernel part of same table? How do we
make sure that sufficient space is available. I am not sure if possible
table corruption from crashed kernel is an issue here or not.
In general, I think changelogs of these patches need to be little better.
There seem to be lot of text and still I can't quickly wrap my head around
what a particular patch is supposed to be doing.
But we definitely need to fix this issue. IOMMU issues with kdump have
been troubling us for a very long time.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists