[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140306064756.GB16859@needle.mulix.org>
Date: Thu, 6 Mar 2014 08:47:56 +0200
From: Muli Ben-Yehuda <muli@...technion.ac.il>
To: WANG Chao <chaowang@...hat.com>
Cc: "Jon D. Mason" <jdmason@...zu.us>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Vivek Goyal <vgoyal@...hat.com>,
Yinghai Lu <yinghai@...nel.org>, Baoquan He <bhe@...hat.com>,
kexec@...ts.infradead.org, discuss@...-64.org, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: How could we get rid of saved_max_pfn for calgary iommu?
On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
> Hi, Muli
>
> saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
> could get rid of saved_max_pfn at all. But If this can't work, how
> about exporting a calgary tce table size to user space, so that
> kexec-tools can simply pass calgary=xxx cmdline to 2nd kernel.
As Jon noted, this code is used to so that the TCE table remains
consistent between the original and the kexec'd kernel. I see two
options: either we hard code the TCE table size to the max so that
this bit of code becomes redundant, or we explicitly pass the original
table size (or the original max_pfn) to the kexec'd kernel. The first
option is more appealing, because I don't think anyone is actually
using the TCE table size -- we mostly added it for debugging the IOMMU
TCE code at the time -- but since I don't have a Calgary machine
anymore, I don't have any way to test it. The second option is uglier
but would be fully backward-compatible and less likely to break
things. Given that very few people are likely running the latest
upstream kernel on Calgary/CalIOC2 machines, I'm inclined towards the
first option.
> BTW MAINTAINERS file still uses your old email, please update
> accordingly.
I think you are the first person to actually look up the Calgary
maintainers in the last few years :-)
Cheers,
Muli
--
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