From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645Ab2LVDXO (ORCPT ); Fri, 21 Dec 2012 22:23:14 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:54816 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752306Ab2LVDXL (ORCPT ); Fri, 21 Dec 2012 22:23:11 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Konrad Rzeszutek Wilk Cc: Yinghai Lu , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Morton , linux-kernel@vger.kernel.org References: <1355814959-10573-1-git-send-email-yinghai@kernel.org> <1355814959-10573-25-git-send-email-yinghai@kernel.org> <20121222023741.GF3468@phenom.dumpdata.com> <87bodmhkns.fsf@xmission.com> <20121222031019.GA4120@phenom.dumpdata.com> Date: Fri, 21 Dec 2012 19:23:03 -0800 In-Reply-To: <20121222031019.GA4120@phenom.dumpdata.com> (Konrad Rzeszutek Wilk's message of "Fri, 21 Dec 2012 22:10:19 -0500") Message-ID: <87pq22g488.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX19rv4JuyYcyu6i2J/e4lNYOdzmoFDri/pQ= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0001] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Konrad Rzeszutek Wilk X-Spam-Relay-Country: Subject: Re: [PATCH v7 24/27] x86: Add swiotlb force off support X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 03:05:19 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Konrad Rzeszutek Wilk writes: > On Fri, Dec 21, 2012 at 06:42:47PM -0800, Eric W. Biederman wrote: >> Konrad Rzeszutek Wilk 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