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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 721D4C433DF for ; Tue, 25 Aug 2020 19:03:03 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 4AFD92074D for ; Tue, 25 Aug 2020 19:03:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZKDfZJpE"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="sFNWgvXt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4AFD92074D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=15Xzl6EnFroIIbbVdRG6JY8huhDhYZVmi6f2JotVFK8=; b=ZKDfZJpEaevwsHDKbmKcNuwTi UTJz/rPO1Ilon5dukTeSJ/JqBlykXDcMcHWqk4Hm6QPU3q5jaRUl62xiUenlU8QwVvpoeGk/zFH9Z KL/4EO7QnlgpZNaj7Pl0uHCCM+jWiRa2wLZWgRDPNjsYgxYGLimoLaa55ZX9b1WPPXiCSbifudwlN fRUzehUTDZGAB9i7CqTwkJALEbwrjQfZf7LbwUuyM70CHmktxu8Oh1JLNrqt9qGzJx9isEI6EZBlD M3R1F8tDxuREUX/fwbq2oC2DeliMv2gk5ZSy1xnyDkFAOI/PYTE01AXvG1ogiNuwmkJRI2pnQF/44 XqjfzJevw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAeCO-0002Z9-Rq; Tue, 25 Aug 2020 19:01:36 +0000 Received: from m43-7.mailgun.net ([69.72.43.7]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAeCF-0002Xq-FJ for linux-arm-kernel@lists.infradead.org; Tue, 25 Aug 2020 19:01:34 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1598382092; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=TRQuySeZQtx9Xu8p/LTvIapZAq6d9k1oOwhDjvqNYBE=; b=sFNWgvXtryGCKy9vnwBie+9jVXIsQCZ5ULy6VqAAebR24ugRkxcIMVyWEgLJHImDne8R86B5 OyizBqlmyDuswB+iDZ+jbFU0bvYKTUR6dOXqqwXnPf7F5sHRtndmBClETf0oC/kGbwNLXl3/ 1LF5DEzlnPofZxQZqfgIPYXBbAM= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n02.prod.us-west-2.postgun.com with SMTP id 5f455fd7e82a078aef9ae48b (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 25 Aug 2020 19:00:39 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 32296C433A0; Tue, 25 Aug 2020 19:00:39 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id 142A3C433CB; Tue, 25 Aug 2020 19:00:38 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 26 Aug 2020 00:30:38 +0530 From: Sai Prakash Ranjan To: Doug Anderson Subject: Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names In-Reply-To: References: <20200825154249.20011-1-saiprakash.ranjan@codeaurora.org> Message-ID: <3df7edd53ebca00be288e69b92b8d4b9@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200825_150133_181215_8DE9F247 X-CRM114-Status: GOOD ( 37.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Will Deacon , Joerg Roedel , LKML , Stephen Boyd , iommu@lists.linux-foundation.org, linux-arm-msm , Tomasz Figa , Robin Murphy , Linux ARM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On 2020-08-25 21:40, Doug Anderson wrote: > Hi, > > On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan > wrote: >> >> Currently the non-strict or lazy mode of TLB invalidation can only be >> set >> for all or no domains. This works well for development platforms where >> setting to non-strict/lazy mode is fine for performance reasons but on >> production devices, we need a more fine grained control to allow only >> certain peripherals to support this mode where we can be sure that it >> is >> safe. So add support to filter non-strict/lazy mode based on the >> device >> names that are passed via cmdline parameter "iommu.nonstrict_device". >> >> Example: >> iommu.nonstrict_device="7c4000.sdhci,a600000.dwc3,6048000.etr" > > I have an inherent dislike of jamming things like this onto the > command line. IMHO the command line is the last resort for specifying > configuration and generally should be limited to some specialized > debug options and cases where the person running the kernel needs to > override a config that was set by the person (or company) compiling > the kernel. Specifically, having a long/unwieldy command line makes > it harder to use for the case when an end user actually wants to use > it to override something. It's also just another place to look for > config. > Good thing about command line parameters are that they are optional, they do not specify any default behaviour (I mean they are not mandatory to be set for the system to be functional), so I would like to view it as an optional config. And this command line parameter (nonstrict_device) is strictly optional with default being strict already set in the driver. They can be passed from the bootloader via chosen node for DT platforms or choose a new *bootconfig* as a way to pass the cmdline but finally it does boil down to just another config. I agree with general boolean or single value command line parameters being just more messy which could just be Kconfigs instead but for multiple value parameters like these do not fit in Kconfig. As you might already know, command line also gives an advantage to the end user to configure system without building kernel, for this specific command line its very useful because the performance bump is quite noticeable when the iommu.strict is off. Now for end user who would not be interested in building entire kernel(majority) and just cares about good speeds or throughput can find this very beneficial. I am not talking about one specific OS usecase here but more in general term. > The other problem is that this doesn't necessarily scale very well. > While it works OK for embedded cases it doesn't work terribly well for > distributions. I know that in an out-of-band thread you indicated > that it doesn't break anything that's not already broken (AKA this > doesn't fix the distro case but it doesn't make it worse), it would be > better to come up with a more universal solution. > Is the universal solution here referring to fix all the command line parameters in the kernel or this specific command line? Are we going to remove any more addition to the cmdline ;) So possible other solution is the *bootconfig* which is again just another place to look for a config. So thing is that this universal solution would result in just more new fancy ways of passing configs or adding such configs to the drivers or subsystems in kernel which is pretty much similar to implementing policy in kernel which I think is frowned upon and mentioned in the other thread. > Ideally it feels like we should figure out how to tag devices in a > generic manner automatically (hardcode at the driver or in the device > tree). I think the out-of-band discussions talked about "external > facing" and the like. We could also, perhaps, tag devices that have > "binary blob" firmware if we wanted. Then we'd have a policy (set by > Kconfig, perhaps overridable via commandline) that indicated the > strictness level for the various classes of devices. So policy would > be decided by KConfig and/or command line. > How is tagging in driver or device tree better than the simple command line approach to pass the same list of devices which otherwise you would hardcode in the corresponding drivers and device tree all over the kernel other than the scalability part for command line? IMHO it is too much churn. Device tree could be used but then we have a problem with it being for only describing hardware and it doesn't work for ACPI based systems. Command line approach works for all systems (both DT and ACPI) without having to add too much churn to drivers. Lastly, I think we can have both options, it doesn't hurt to add command line parameter since it is optional. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel