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.4 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,URIBL_BLOCKED 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 AEDD9C07E96 for ; Thu, 8 Jul 2021 14:38:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 6BB3060241 for ; Thu, 8 Jul 2021 14:38:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BB3060241 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=w0Cpt8ZLQ4dMpB7M2a7wvCun227iQygOgzGbaJHiymQ=; b=csoL9pJ4SB5lPd NyM03qJ0T1UgjSFXXRTl3FZje4LDg8rcHjYEZKBWLkhL+7BD/T1w0IpO7rVcXA+Cea8zHM4r36Zkd MdfiqTx0IvzDOnYUhtFbnxCdWHHNwvwQsrzCtkeyfDQEQ4ay8PH4y2OkhQRX4N865f9F+zFhux+eX goROEUjwJWLMRceBUS7oWv6c18Xih0DqLge5UOWDsaCnfD+6doRX8Sd8p/X8sWDwuhMNZzyHShUvu Qtqifxy1tBllrbw9Y2PlF7gi1ryGTsNedQH77miqYHwEwgnY8OptdxmU/nueQPR/WoA09kxkIA8Ow v8nqVAdzy4LNfgObEX6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m1V93-00HD3B-3i; Thu, 08 Jul 2021 14:36:53 +0000 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m1V8x-00HD1d-2u for linux-arm-kernel@lists.infradead.org; Thu, 08 Jul 2021 14:36:50 +0000 Received: by mail-qt1-x835.google.com with SMTP id c9so916973qte.6 for ; Thu, 08 Jul 2021 07:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72Nulo0ReEKh1o09njcEPjT3ZEsb/u/uPS+kUmVy8sU=; b=FWRbODpJvUDW1Hvvw6jBbIxh3B4HQaPFbePSQUSLSnU3oLIOtqDyL5r0r30yICdLR5 yPDKdQ08N64edmb3D42lPuwAt1byFqGLzD6Q9oAWRnvo2NBTHJameLigCEbX0UTLUCUf YeA2vARMIdIU5/CZ+Oz55gYoydq3XkuhCgH0U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=72Nulo0ReEKh1o09njcEPjT3ZEsb/u/uPS+kUmVy8sU=; b=D/QAB0sHAiTW8s4HxX8Gch0i1qLZ0TmPYBJVcLZadVoEO2X6RMKPET+3Ib1+i2ApxA nVhkzFz+LHtoQvj64cyEF+nQNms1VlDWMMnt6gNDIztl5koBqHLuy/+Jcc1LwW2EYYzo wUPUysSDTd6FGqlegX+4z3NVDivzvnwjvk/no1llDMf2No5vJATcUNG5IBroC1e++lLA QFDvo32M0suOAZV/7v+3P09SHwdohrSTw7sP4OgNOS5FazWRrzD7Dly88PYWr7PpWaPe OIdDLZzxGi2PRsxoyFwuDg55xMeHETRDiKGuWgewu7IJXB6uCz7Z1pYAYFyoKFNwEvjH Igog== X-Gm-Message-State: AOAM532U/uRVC2flHWwl2O2hMNyF5Io1IipS3olEp9Kzo2uBndUNKFQ+ JGbE40Xxoq57E8cLmVO/8FweCNHC17dDVQ== X-Google-Smtp-Source: ABdhPJxoVaHzci5x32CR5e1lR7lQuqNnsZ/NEldpeaXS9sYLl7WKFh2fFsEMmK7Wkxd4e+aNWIzVEQ== X-Received: by 2002:ac8:5941:: with SMTP id 1mr27831059qtz.28.1625755005493; Thu, 08 Jul 2021 07:36:45 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id y20sm1074211qkm.5.2021.07.08.07.36.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jul 2021 07:36:44 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id b13so9312593ybk.4 for ; Thu, 08 Jul 2021 07:36:44 -0700 (PDT) X-Received: by 2002:a25:6088:: with SMTP id u130mr41384789ybb.257.1625754992872; Thu, 08 Jul 2021 07:36:32 -0700 (PDT) MIME-Version: 1.0 References: <20210624171759.4125094-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Thu, 8 Jul 2021 07:36:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC To: Joerg Roedel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210708_073647_157771_27AFB33A X-CRM114-Status: GOOD ( 35.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Linux Doc Mailing List , Peter Zijlstra , linux-pci@vger.kernel.org, Konrad Dybcio , Jordan Crouse , Thierry Reding , Joel Fernandes , Rajat Jain , Will Deacon , Rob Clark , Sai Prakash Ranjan , Saravana Kannan , Jonathan Corbet , quic_c_gdjako@quicinc.com, Linux ARM , Viresh Kumar , Veerabhadrarao Badiganti , "Paul E. McKenney" , linux-arm-msm , John Garry , Nicolin Chen , Bjorn Helgaas , Bjorn Andersson , Sonny Rao , Vlastimil Babka , Randy Dunlap , Linux MMC List , Adrian Hunter , LKML , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Andrew Morton , Robin Murphy , "Maciej W. Rozycki" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, Jul 8, 2021 at 1:09 AM Joerg Roedel wrote: > > On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote: > > a) Nothing is inherently broken with my current approach. > > > > b) My current approach doesn't make anybody terribly upset even if > > nobody is totally in love with it. > > Well, no, sorry :) > > I don't think it is a good idea to allow drivers to opt-out of the > strict-setting. This is a platform or user decision, and the driver > should accept whatever it gets. Sure, I agree with you there. The driver shouldn't ever be able to override and make things less strict than the user or platform wants. It feels like that can be accomplished. See below. > So the real question is still why strict is the default setting and how > to change that. I guess there are two strategies if we agree that there's a benefit to running some devices in strict and others in non-strict: * opt-in to strict: default is non-strict and we have to explicitly list what we want to be strict. * opt-out of strict: default is strict and we have to explicitly list what we want to be non-strict. I guess the question is: do we allow both strategies or only one of them? I think you are suggesting that the kernel should support "opt-in" to strict and that that matches the status quo with PCI on x86. I'm pushing for some type of "opt-out" of strict support. I have heard from security folks that they'd prefer "opt-out" of strict as well. If we're willing to accept more complex config options we could support both choosable by KConfig. How it'd all work in my mind: Command line: * iommu.strict=0 - suggest non-strict by default * iommu.strict=1 - force strict for all drivers * iommu.strict not specified - no opinion Kconfig: * IOMMU_DEFAULT_LAZY - suggest non-strict by default; drivers can opt-in to strict * IOMMU_DEFAULT_STRICT - force strict for all drivers * IOMMU_DEFAULT_LOOSE_STRICT - allow explicit suggestions for laziness but default to strict if no votes. Drivers: * suggest lazy - suggest non-strict * force strict - force strict * no vote How the above work together: * if _any_ of the three things wants strict then it's strict. * if _all_ of the three things want lazy then it's lazy. * If the KConfig is "loose strict" and the command line is set to "lazy" then it's equivalent to the KConfig saying "lazy". In other words drivers could still "opt-in" to strict but otherwise we'd be lazy. * The only way for a driver's "suggest lazy" vote to have any effect at all is if "iommu.strict" wasn't specified on the command line _and_ if the KConfig was "loose strict". This is effectively the "opt-out" of lazy. If you think the strategy I describe above is garbage then would you be OK if I re-worked my patchset to at least allow non-PCI drivers to "opt-in" to strict? Effectively I'd change patch #3 to list all of the peripherals on my SoC _except_ the USB and SD/MMC and request that they all be strict. If other people expressed their preference for the "opt-out" of strict strategy would that change your mind? > Or document for the users that want performance how to > change the setting, so that they can decide. Pushing this to the users can make sense for a Linux distribution but probably less sense for an embedded platform. So I'm happy to make some way for a user to override this (like via kernel command line), but I also strongly believe there should be a default that users don't have to futz with that we think is correct. -Doug _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel