[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150112161538.GB16162@redhat.com>
Date: Mon, 12 Jan 2015 11:15:38 -0500
From: Vivek Goyal <vgoyal@...hat.com>
To: Joerg Roedel <joro@...tes.org>
Cc: "Li, Zhen-Hua" <zhen-hual@...com>, dwmw2@...radead.org,
indou.takao@...fujitsu.com, bhe@...hat.com, dyoung@...hat.com,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
alex.williamson@...hat.com, ddutile@...hat.com,
ishii.hironobu@...fujitsu.com, bhelgaas@...gle.com,
doug.hatch@...com, jerry.hoemann@...com, tom.vaden@...com,
li.zhang6@...com, lisa.mitchell@...com, billsumnerlinux@...il.com,
rwright@...com
Subject: Re: [PATCH v8 02/10] iommu/vt-d: Items required for kdump
On Mon, Jan 12, 2015 at 05:06:46PM +0100, Joerg Roedel wrote:
> On Mon, Jan 12, 2015 at 10:29:19AM -0500, Vivek Goyal wrote:
> > Kdump has the notion of backup region. Where certain parts of old kernels
> > memory can be moved to a different location (first 640K on x86 as of now)
> > and new kernel can make use of this memory now.
> >
> > So we will have to just make sure that no parts of this old page table
> > fall into backup region.
>
> Uuh, looks like the 'iommu-with-kdump-issue' isn't complicated enough
> yet ;)
> Sadly, your above statement is true for all hardware-accessible data
> structures in IOMMU code. I think about how we can solve this, is there
> an easy way to allocate memory that is not in any backup region?
Hmm..., there does not seem to be any easy way to do this. In fact, as of
now, kernel does not even know where is backup region. All these details are
managed by user space completely (except for new kexec_file_load() syscall).
That means we are left with ugly options now.
- Define per arch kexec backup regions in kernel and export it to user
space and let kexec-tools make use of that deinition (instead of
defining its own). That way memory allocation code in kernel can look
at this backup area and skip it for certain allocations.
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