From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id E2DCD7D08A for ; Wed, 17 Apr 2019 02:37:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729097AbfDQChN (ORCPT ); Tue, 16 Apr 2019 22:37:13 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:51496 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727063AbfDQChN (ORCPT ); Tue, 16 Apr 2019 22:37:13 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 051CDC13ADFA5248D7C5; Wed, 17 Apr 2019 10:37:10 +0800 (CST) Received: from [127.0.0.1] (10.177.23.164) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.408.0; Wed, 17 Apr 2019 10:37:00 +0800 Subject: Re: [PATCH v5 1/6] iommu: add generic boot option iommu.dma_mode To: Will Deacon , Robin Murphy References: <20190409125308.18304-1-thunder.leizhen@huawei.com> <20190409125308.18304-2-thunder.leizhen@huawei.com> <010d3cbd-ef74-ad21-c735-0af8b18955e6@huawei.com> <222946ee-adcc-1311-82a7-6afc9ffbc846@arm.com> <20190416152100.GB4187@fuggles.cambridge.arm.com> CC: John Garry , Jean-Philippe Brucker , Joerg Roedel , "Jonathan Corbet" , linux-doc , Sebastian Ott , Gerald Schaefer , "Martin Schwidefsky" , Heiko Carstens , Benjamin Herrenschmidt , Paul Mackerras , "Michael Ellerman" , Tony Luck , Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , David Woodhouse , iommu , linux-kernel , linux-s390 , linuxppc-dev , x86 , linux-ia64 , Hanjun Guo From: "Leizhen (ThunderTown)" Message-ID: <5CB6914A.8050308@huawei.com> Date: Wed, 17 Apr 2019 10:36:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20190416152100.GB4187@fuggles.cambridge.arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 2019/4/16 23:21, Will Deacon wrote: > On Fri, Apr 12, 2019 at 02:11:31PM +0100, Robin Murphy wrote: >> On 12/04/2019 11:26, John Garry wrote: >>> On 09/04/2019 13:53, Zhen Lei wrote: >>>> +static int __init iommu_dma_mode_setup(char *str) >>>> +{ >>>> + if (!str) >>>> + goto fail; >>>> + >>>> + if (!strncmp(str, "passthrough", 11)) >>>> + iommu_default_dma_mode = IOMMU_DMA_MODE_PASSTHROUGH; >>>> + else if (!strncmp(str, "lazy", 4)) >>>> + iommu_default_dma_mode = IOMMU_DMA_MODE_LAZY; >>>> + else if (!strncmp(str, "strict", 6)) >>>> + iommu_default_dma_mode = IOMMU_DMA_MODE_STRICT; >>>> + else >>>> + goto fail; >>>> + >>>> + pr_info("Force dma mode to be %d\n", iommu_default_dma_mode); >>> >>> What happens if the cmdline option iommu.dma_mode is passed multiple >>> times? We get mutliple - possibily conflicting - prints, right? >> >> Indeed; we ended up removing such prints for the existing options here, >> specifically because multiple messages seemed more likely to be confusing >> than useful. I originally intended to be compatible with X86 printing. } else if (!strncmp(str, "strict", 6)) { pr_info("Disable batched IOTLB flush\n"); intel_iommu_strict = 1; } >> >>> And do we need to have backwards compatibility, such that the setting >>> for iommu.strict or iommu.passthrough trumps iommu.dma_mode, regardless >>> of order? >> >> As above I think it would be preferable to just keep using the existing >> options anyway. The current behaviour works out as: >> >> iommu.passthrough | Y | N >> iommu.strict | x | Y N >> ------------------|-------------|---------|-------- >> MODE | PASSTHROUGH | STRICT | LAZY >> >> which seems intuitive enough that a specific dma_mode option doesn't add >> much value, and would more likely just overcomplicate things for users as >> well as our implementation. > > Agreed. We can't remove the existing options, and they do the job perfectly > well so I don't see the need to add more options on top. OK, I will remove the iommu.dma_mode option in the next version. Thanks for you three. I didn't want to add it at first, but later found that the boot options on each ARCH are different, then want to normalize it. In addition, do we need to compatible the build option name IOMMU_DEFAULT_PASSTHROUGH? or change it to IOMMU_DEFAULT_DMA_MODE_PASSTHROUGH or IOMMU_DEFAULT_MODE_PASSTHROUGH? > > Will > > . > -- Thanks! BestRegards