[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pq22g488.fsf@xmission.com>
Date: Fri, 21 Dec 2012 19:23:03 -0800
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Yinghai Lu <yinghai@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 24/27] x86: Add swiotlb force off support
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> writes:
> On Fri, Dec 21, 2012 at 06:42:47PM -0800, Eric W. Biederman wrote:
>> Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> writes:
>>
>> > On Mon, Dec 17, 2012 at 11:15:56PM -0800, Yinghai Lu wrote:
>> >> So use could disable swiotlb from command line, even swiotlb support
>> >> is compiled in. Just like we have intel_iommu=on and intel_iommu=off.
>> >
>> > You really need to spell out why this is useful.
>>
>> YH why can't we safely autodetect that the swiotlb is unusable when
>> there is no memory below 4G free?
>
> I am not sure what 'YH' stands for (Yeah?).
Yinghai Lu's nickname.
> However we could turn SWIOTLB off altogether if it cannot allocate
> _some_ memory. It could try first 64MB, then 32MB, lastly 16MB. And
> if all that fails - print a nice warning and continue on.
>
> Later in the late initialization phase, when pci_swiotlb_late_init
> is called - it can then figure out whether 'iommu' has been set
> and it iself was never able to allocate. At that point it can try
> the dynamic allocation (swiotlb_late_init_with_default_size)
> ... and if that fails give up and panic.
As far as I can tell panics should be avoided unless there is something
that actually needs an iommu, and the swiommu is the only option, and
the swiommu can not fulfill that request.
In this case YH has been working on the case of loading a kernel
completely above 4G, and apparently he has also been testing the case of
running a kernel with no memory below 4G.
Eric
--
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