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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 992A1C49EA4 for ; Tue, 22 Jun 2021 19:56:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 803876135A for ; Tue, 22 Jun 2021 19:56:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232741AbhFVT6o (ORCPT ); Tue, 22 Jun 2021 15:58:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232755AbhFVT6n (ORCPT ); Tue, 22 Jun 2021 15:58:43 -0400 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62C59C061766 for ; Tue, 22 Jun 2021 12:56:27 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id d9so360301qtx.8 for ; Tue, 22 Jun 2021 12:56:27 -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=N93FQS54KNMw/RWZd3sdd1/c5zsgaKSRIH5cGtG3wLQ=; b=nKSDq/oCJcM6qZHdPsZIzNgBCyluw3srCscilwpHd/8GiydqZY43q/T3vv2Nn2jbKD jegHEFKq7oKJUZmrnbp2L6fkE3vgH2JXF/RfOrax19gy3NpN1urkxXl0RO3exPK9Eg/i cQzl2nnV7iu4Ug4cNN87vHMj6sK4LHNEdz+OI= 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=N93FQS54KNMw/RWZd3sdd1/c5zsgaKSRIH5cGtG3wLQ=; b=WxDh4sg81G7PWgk0GZFdMWELvuvgsAU3JY8jbVU+DiTLtpb9DB5NZmn3WW3XiXeUrV S3SlVT+IBfObuGUbiTFc0Xf1SbcTs8soGB3H5jcyFrJopip24ramHWQ+7TUdmM7z8RH8 BpAGhfBh86KDy69XKqUQE+t5ZADnGvrq52kQrF69Y8cQSkpydU61+XsHKx6aOKKLsqZD dAxHUcKCT2I6n74HhPeM8V7hx769hAI/A/FdrLM8LYe0SsGu5tqEI4eI+KXiGs7QgIrK aBTaj703kJ86OQjJ5gTe1/VVVW5B3LCtIs7CWKw79yziJxwzClxvDgRJNZh3IhNBxMY3 16PA== X-Gm-Message-State: AOAM530siNA7ECkkdWi2yt8HSqW5CtvqqcjBoTKK73bDGRR2mI846DVH 7s9wnkQfwXLA004tilsqm12n85XiNymvYw== X-Google-Smtp-Source: ABdhPJz5jRIJ5Y3KqetmAFk2kwAEiK/W1idRezxptrxxOSWoZ32Z1SOZmtci8kO2YE6q/89rrnTOrA== X-Received: by 2002:ac8:5e12:: with SMTP id h18mr414349qtx.253.1624391786437; Tue, 22 Jun 2021 12:56:26 -0700 (PDT) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com. [209.85.222.178]) by smtp.gmail.com with ESMTPSA id c20sm2543822qtm.52.2021.06.22.12.56.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Jun 2021 12:56:26 -0700 (PDT) Received: by mail-qk1-f178.google.com with SMTP id o6so7334164qkh.4 for ; Tue, 22 Jun 2021 12:56:26 -0700 (PDT) X-Received: by 2002:a25:2405:: with SMTP id k5mr6836288ybk.405.1624391426495; Tue, 22 Jun 2021 12:50:26 -0700 (PDT) MIME-Version: 1.0 References: <20210621235248.2521620-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Tue, 22 Jun 2021 12:50:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC To: John Garry Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Will Deacon , Robin Murphy , Joerg Roedel , Bjorn Andersson , Ulf Hansson , Adrian Hunter , Bjorn Helgaas , Rob Clark , linux-arm-msm , linux-pci@vger.kernel.org, quic_c_gdjako@quicinc.com, "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Sonny Rao , Sai Prakash Ranjan , Linux MMC List , Veerabhadrarao Badiganti , Rajat Jain , Saravana Kannan , Joel Fernandes , Andy Gross , Bartosz Golaszewski , Dan Williams , Geert Uytterhoeven , Heikki Krogerus , Randy Dunlap , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, On Tue, Jun 22, 2021 at 10:46 AM John Garry wrote: > > On 22/06/2021 00:52, Douglas Anderson wrote: > > > > This patch attempts to put forward a proposal for enabling non-strict > > DMA on a device-by-device basis. The patch series requests non-strict > > DMA for the Qualcomm SDHCI controller as a first device to enable, > > getting a nice bump in performance with what's believed to be a very > > small drop in security / safety (see the patch for the full argument). > > > > As part of this patch series I am end up slightly cleaning up some of > > the interactions between the PCI subsystem and the IOMMU subsystem but > > I don't go all the way to fully remove all the tentacles. Specifically > > this patch series only concerns itself with a single aspect: strict > > vs. non-strict mode for the IOMMU. I'm hoping that this will be easier > > to talk about / reason about for more subsystems compared to overall > > deciding what it means for a device to be "external" or "untrusted". > > > > If something like this patch series ends up being landable, it will > > undoubtedly need coordination between many maintainers to land. I > > believe it's fully bisectable but later patches in the series > > definitely depend on earlier ones. Sorry for the long CC list. :( > > > > JFYI, In case to missed it, and I know it's not the same thing as you > want, above, but the following series will allow you to build the kernel > to default to lazy mode: > > https://lore.kernel.org/linux-iommu/1624016058-189713-1-git-send-email-john.garry@huawei.com/T/#m21bc07b9353b3ba85f2a40557645c2bcc13cbb3e > > So iommu.strict=0 would be no longer always required for arm64. Excellent! I'm never a fan of command line parameters as a replacement for Kconfig. They are great for debugging or for cases where the user of the kernel and the person compiling the kernel are not the same (like with off-the-shelf Linux distros) but aren't great for setting a default for embedded environments. I actually think that something like my patchset may be even more important atop yours. Do you agree? If the default is non-strict it could be extra important to be able to mark a certain device to be in "strict" mode. ...also, unfortunately I probably won't be able to use your patchest for my use case. I think we want the extra level of paranoia by default and really only want to allow non-strict mode for devices that we're really convinced are safe. -Doug