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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Leizhen (ThunderTown)" Date: Wed, 17 Apr 2019 02:36:58 +0000 Subject: Re: [PATCH v5 1/6] iommu: add generic boot option iommu.dma_mode Message-Id: <5CB6914A.8050308@huawei.com> List-Id: 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> In-Reply-To: <20190416152100.GB4187@fuggles.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Will Deacon , Robin Murphy 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Leizhen (ThunderTown)" Subject: Re: [PATCH v5 1/6] iommu: add generic boot option iommu.dma_mode Date: Wed, 17 Apr 2019 10:36:58 +0800 Message-ID: <5CB6914A.8050308@huawei.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190416152100.GB4187@fuggles.cambridge.arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Will Deacon , Robin Murphy 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 List-Id: iommu@lists.linux-foundation.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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7465AC10F14 for ; Wed, 17 Apr 2019 02:37:16 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 43DB520872 for ; Wed, 17 Apr 2019 02:37:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43DB520872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 0C14BCBE; Wed, 17 Apr 2019 02:37:16 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8A655415 for ; Wed, 17 Apr 2019 02:37:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC0B21C0 for ; Wed, 17 Apr 2019 02:37:13 +0000 (UTC) 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> 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> X-Originating-IP: [10.177.23.164] X-CFilter-Loop: Reflected Cc: linux-ia64 , Sebastian Ott , linux-doc , Benjamin Herrenschmidt , Hanjun Guo , Heiko Carstens , Paul Mackerras , "H . Peter Anvin" , linux-s390 , Jonathan Corbet , Jean-Philippe Brucker , Michael Ellerman , x86 , Ingo Molnar , Fenghua Yu , Borislav Petkov , Thomas Gleixner , Gerald Schaefer , Tony Luck , linuxppc-dev , linux-kernel , iommu , Martin Schwidefsky , David Woodhouse X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Message-ID: <20190417023658.SLAK0UPG5ML9XZThKZqyHuFk5FXl0WFgW6dv-B_T2Eg@z> 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 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2FF9C10F14 for ; Wed, 17 Apr 2019 02:38:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4A53720872 for ; Wed, 17 Apr 2019 02:38:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A53720872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 44kRJ96ZB9zDqN9 for ; Wed, 17 Apr 2019 12:38:49 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=huawei.com (client-ip=45.249.212.32; helo=huawei.com; envelope-from=thunder.leizhen@huawei.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=huawei.com Received: from huawei.com (szxga06-in.huawei.com [45.249.212.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44kRGN6zwkzDqMW for ; Wed, 17 Apr 2019 12:37:16 +1000 (AEST) 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> 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 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64 , Sebastian Ott , linux-doc , Hanjun Guo , Heiko Carstens , Paul Mackerras , "H . Peter Anvin" , linux-s390 , Jonathan Corbet , Jean-Philippe Brucker , Joerg Roedel , x86 , Ingo Molnar , Fenghua Yu , John Garry , Borislav Petkov , Thomas Gleixner , Gerald Schaefer , Tony Luck , linuxppc-dev , linux-kernel , iommu , Martin Schwidefsky , David Woodhouse Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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