From: "H. Peter Anvin" <hpa@zytor.com>
To: Muli Ben-Yehuda <muli@cs.technion.ac.il>,
WANG Chao <chaowang@redhat.com>
Cc: discuss@x86-64.org, Baoquan He <bhe@redhat.com>,
x86@kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, "Jon D. Mason" <jdmason@kudzu.us>,
Thomas Gleixner <tglx@linutronix.de>,
Yinghai Lu <yinghai@kernel.org>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: How could we get rid of saved_max_pfn for calgary iommu?
Date: Wed, 05 Mar 2014 22:50:41 -0800 [thread overview]
Message-ID: <53181AC1.2020807@zytor.com> (raw)
In-Reply-To: <20140306064756.GB16859@needle.mulix.org>
On 03/05/2014 10:47 PM, Muli Ben-Yehuda wrote:
> 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 :-)
>
OK, second question... is it time to axe Calgary?
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Muli Ben-Yehuda <muli@cs.technion.ac.il>,
WANG Chao <chaowang@redhat.com>
Cc: "Jon D. Mason" <jdmason@kudzu.us>,
Thomas Gleixner <tglx@linutronix.de>,
Vivek Goyal <vgoyal@redhat.com>, Yinghai Lu <yinghai@kernel.org>,
Baoquan He <bhe@redhat.com>,
kexec@lists.infradead.org, discuss@x86-64.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: How could we get rid of saved_max_pfn for calgary iommu?
Date: Wed, 05 Mar 2014 22:50:41 -0800 [thread overview]
Message-ID: <53181AC1.2020807@zytor.com> (raw)
In-Reply-To: <20140306064756.GB16859@needle.mulix.org>
On 03/05/2014 10:47 PM, Muli Ben-Yehuda wrote:
> 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 :-)
>
OK, second question... is it time to axe Calgary?
-hpa
next prev parent reply other threads:[~2014-03-06 6:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-19 6:18 How could we get rid of saved_max_pfn for calgary iommu? WANG Chao
2014-02-19 6:18 ` WANG Chao
2014-02-20 0:04 ` Jon Mason
2014-02-20 0:04 ` Jon Mason
2014-02-20 2:36 ` Vivek Goyal
2014-02-20 2:36 ` Vivek Goyal
2014-02-21 7:47 ` WANG Chao
2014-02-21 7:47 ` WANG Chao
2014-02-21 8:18 ` Baoquan He
2014-02-21 8:18 ` Baoquan He
2014-03-05 5:36 ` WANG Chao
2014-03-05 5:36 ` WANG Chao
2014-03-06 6:47 ` Muli Ben-Yehuda
2014-03-06 6:47 ` Muli Ben-Yehuda
2014-03-06 6:50 ` H. Peter Anvin [this message]
2014-03-06 6:50 ` H. Peter Anvin
2014-03-06 7:00 ` Muli Ben-Yehuda
2014-03-06 7:00 ` Muli Ben-Yehuda
2014-03-06 14:46 ` Jon Mason
2014-03-06 14:46 ` Jon Mason
2014-03-09 7:06 ` Muli Ben-Yehuda
2014-03-09 7:06 ` Muli Ben-Yehuda
2014-03-11 5:20 ` Jon Mason
2014-03-11 5:20 ` Jon Mason
2014-03-06 16:05 ` Vivek Goyal
2014-03-06 16:05 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53181AC1.2020807@zytor.com \
--to=hpa@zytor.com \
--cc=bhe@redhat.com \
--cc=chaowang@redhat.com \
--cc=discuss@x86-64.org \
--cc=jdmason@kudzu.us \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@cs.technion.ac.il \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.