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=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 1BB9BC49EA5 for ; Thu, 24 Jun 2021 13:42:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0052861057 for ; Thu, 24 Jun 2021 13:42:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230170AbhFXNog (ORCPT ); Thu, 24 Jun 2021 09:44:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229878AbhFXNof (ORCPT ); Thu, 24 Jun 2021 09:44:35 -0400 Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56668C061574 for ; Thu, 24 Jun 2021 06:42:16 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id h10so3295666qvz.2 for ; Thu, 24 Jun 2021 06:42:16 -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=yRRpyknNOYu61oOPsy3QfFe0DlnKqFXOFR/ODDvOpRA=; b=UtHXwFYLTrHgPc145mL3C9UB4ey+/nLdjIs7pvzujRNmQ5EAW+afyVO5yMkpxhaiYq EaZ0co1eAfBn5+AQMs9Q4Do4a1gFTjywNfS2sa9OFA0yAfKs040r9gAZmmies4dijQrQ 9P1VJDPAdAgvB5owtJUn6dZ/rn754Mfv82gBk= 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=yRRpyknNOYu61oOPsy3QfFe0DlnKqFXOFR/ODDvOpRA=; b=IkyM9TylO5Sh0U2LLWPZdVbC0p9H+S/hi95Nfb9NzCClyOnSyvaUXtwFrA8jrWW8vo RVS7MiIMywltjZCDDUDBzIEEC/yl4wLKGK4tcZ6dmtCsZrGj2k+baV+Ac6Vly8Wdp79+ V4B4bU/zsrHVjjv4LSZ8f8sl59EtTa4EseLdtxBxNPfjmDpMTDSYWNaBwT2szW6qEVw+ n2MkGPNfcqzcBvTYAMLz5I+Y/F9AcNvd+9LzcL1RpM9vzaMaZ7Wl9i4GdFa4T1wSA9Lg eGpZpEKimTAX1S7TbOaNHlMlT7Xr3612nBnoXmQzdJOJ1eL9cvr6wuEY7jP3jEGRljvW f0gw== X-Gm-Message-State: AOAM53387WOwUVznZtCuHWVdmCx17Hz4yEI5hP+rsU5LqwRmjXpuNYs4 wWSHBug3Y00Gcr3va7GLjzFjxc3AURXqHA== X-Google-Smtp-Source: ABdhPJwxk9kx3jR4miVpfFhpwT5quFdN40UvZ7F8ARS+qwBZNty/2/95orF1MvhjlynabGS2zkv4Rw== X-Received: by 2002:a0c:ba05:: with SMTP id w5mr5561309qvf.60.1624542135473; Thu, 24 Jun 2021 06:42:15 -0700 (PDT) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com. [209.85.222.179]) by smtp.gmail.com with ESMTPSA id o21sm2603097qkp.51.2021.06.24.06.42.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Jun 2021 06:42:14 -0700 (PDT) Received: by mail-qk1-f179.google.com with SMTP id 19so4213664qky.13 for ; Thu, 24 Jun 2021 06:42:14 -0700 (PDT) X-Received: by 2002:a25:6088:: with SMTP id u130mr5223275ybb.257.1624542133615; Thu, 24 Jun 2021 06:42:13 -0700 (PDT) MIME-Version: 1.0 References: <20210621235248.2521620-1-dianders@chromium.org> <20210621165230.2.Icfe7cbb2cc86a38dde0ee5ba240e0580a0ec9596@changeid> In-Reply-To: From: Doug Anderson Date: Thu, 24 Jun 2021 06:42:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] drivers: base: Add bits to struct device to control iommu strictness To: Greg KH Cc: "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 , Bartosz Golaszewski , Dan Williams , 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 Thu, Jun 24, 2021 at 6:37 AM Greg KH wrote: > > On Mon, Jun 21, 2021 at 04:52:44PM -0700, Douglas Anderson wrote: > > How to control the "strictness" of an IOMMU is a bit of a mess right > > now. As far as I can tell, right now: > > * You can set the default to "non-strict" and some devices (right now, > > only PCI devices) can request to run in "strict" mode. > > * You can set the default to "strict" and no devices in the system are > > allowed to run as "non-strict". > > > > I believe this needs to be improved a bit. Specifically: > > * We should be able to default to "strict" mode but let devices that > > claim to be fairly low risk request that they be run in "non-strict" > > mode. > > * We should allow devices outside of PCIe to request "strict" mode if > > the system default is "non-strict". > > > > I believe the correct way to do this is two bits in "struct > > device". One allows a device to force things to "strict" mode and the > > other allows a device to _request_ "non-strict" mode. The asymmetry > > here is on purpose. Generally if anything in the system makes a > > request for strictness of something then we want it strict. Thus > > drivers can only request (but not force) non-strictness. > > > > It's expected that the strictness fields can be filled in by the bus > > code like in the patch ("PCI: Indicate that we want to force strict > > DMA for untrusted devices") or by using the new pre_probe concept > > introduced in the patch ("drivers: base: Add the concept of > > "pre_probe" to drivers"). > > > > Signed-off-by: Douglas Anderson > > --- > > > > include/linux/device.h | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/include/linux/device.h b/include/linux/device.h > > index f1a00040fa53..c1b985e10c47 100644 > > --- a/include/linux/device.h > > +++ b/include/linux/device.h > > @@ -449,6 +449,15 @@ struct dev_links_info { > > * and optionall (if the coherent mask is large enough) also > > * for dma allocations. This flag is managed by the dma ops > > * instance from ->dma_supported. > > + * @force_strict_iommu: If set to %true then we should force this device to > > + * iommu.strict regardless of the other defaults in the > > + * system. Only has an effect if an IOMMU is in place. > > Why would you ever NOT want to do this? > > > + * @request_non_strict_iommu: If set to %true and there are no other known > > + * reasons to make the iommu.strict for this device, > > + * then default to non-strict mode. This implies > > + * some belief that the DMA master for this device > > + * won't abuse the DMA path to compromise the kernel. > > + * Only has an effect if an IOMMU is in place. > > This feels in contrast to the previous field you just added, how do they > both interact? Would an enum work better? Right that it never makes sense to set both bits so an enum could work better, essentially it would be { dont_care, request_non_strict, force_strict }. In any case the whole idea of doing this at the device level looks like it's not the right way to go anyway, so this patch and the previous pre_probe one are essentially abandoned and I need to send out a v2 with some different approaches. -Doug