[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140221081806.GB1635@dhcp-16-105.nay.redhat.com>
Date: Fri, 21 Feb 2014 16:18:06 +0800
From: Baoquan He <bhe@...hat.com>
To: Jon Mason <jdmason@...zu.us>
Cc: WANG Chao <chaowang@...hat.com>, Muli Ben-Yehuda <muli@...ibm.com>,
discuss@...-64.org, x86@...nel.org, kexec@...ts.infradead.org,
linux-kernel <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Yinghai Lu <yinghai@...nel.org>,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: How could we get rid of saved_max_pfn for calgary iommu?
On 02/19/14 at 05:04pm, Jon Mason wrote:
> On Tue, Feb 18, 2014 at 11:18 PM, WANG Chao <chaowang@...hat.com> wrote:
> > Hi, All
> >
> > arch/x86/kernel/pci-calgary.c is the only user of saved_max_pfn today:
> >
> > int __init detect_calgary(void)
> > {
> > [..]
> > specified_table_size = determine_tce_table_size((is_kdump_kernel() ?
> > saved_max_pfn : max_pfn) * PAGE_SIZE);
> > [..]
> > }
>
> IIUC, the purpose of this code is to reuse the TCE table from the
> previous kernel. Thus, it needs to be of the same size as the
> pre-kdump kernel. It is using the max_pfn to determine the TCE table
> size in the non-kdump case. If there is another way to determine the
> size it used before, then I am fine making the change to use that way.
>From code the size is from 64K to 8M, saved_max_pfn is needed to get
this. Could it be a fixed size for TCE table? If this can be a fixed
value, E.g 8M, saved_max_pfn will be not needed any more though a
little memory may be wasted if total ram is smaller than 4G.
Baoquan
Thanks
>
--
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