Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp747887ybt; Wed, 17 Jun 2020 12:56:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyMMQram1MF7LDbZvrsJ06gmxRECr/rNId8VzwsoGIfy8EHx4twRUbWmShyoREFdg5PyL1 X-Received: by 2002:a17:906:a288:: with SMTP id i8mr801385ejz.324.1592423765168; Wed, 17 Jun 2020 12:56:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592423765; cv=none; d=google.com; s=arc-20160816; b=xdMnabhR45OOpI+32UBHEupB2wXK4K8nMsa4k5kuhjh9SO5fwEMCkvcMiil71+2HjF FE0nbf6+5LnLTxPpgJ3nV0/3YdYtS36aTxJfssHOkUU6XKS2m1r73VEredpFXDbxQ02U QqNCUIkmc4derdlILDFzO8qicPzuMQ/OqIk/shBfisAJdo7q5DDtJbY8xnbbcrahDEa2 0PZdEqRjTplrOwY1Vd8a6EOhQV94OZJCEFd0G+oS1vnD3dT9ox/KpSLTYHkHRfBrxiJz vEaIE9exTvV8G37Y1U217+JB8k/IXhAU+oFg0IV92BsMSa53T0Vzocx8gl3WtqhPWJl0 LUiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=652Df2r0/DgKireW06s96KgNYOn5wGhQAsXaGuNmXIU=; b=Pd190hwSIeJdeZjFFwizJhn4cg3IVbfNp65i0u0Af4pW/4/Jg3duMKC5ZVTZaIot6T y2xhWGK9QMmY2TnL2gEtwxKaQkw+eEGiVFYj9wMUrrM8IG53RLktHBho/WWBA9l7rI0b m1EgvetwEk1brXJRdD9WgkQ/3cO3qv2MdKGOCnzkqHOARC3ZD1TfYNOhEkwBF2pB5IZe l4xMWtUeopT0W/YIWhBvtdvoNb9KydXZ4z0S6CGvl1d+oAtT/QEtHvt8nM1RJ/m90rdj L6zOM5MZ8wQ8p/Xdbs8EVMBQV8juAPeBk8r2yGdapdLqki3j16r1RsxDCRX1NWC3+9Pg 3DsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=u3Wa8m8A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dv10si574470ejb.2.2020.06.17.12.55.41; Wed, 17 Jun 2020 12:56:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=u3Wa8m8A; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726899AbgFQTxq (ORCPT + 99 others); Wed, 17 Jun 2020 15:53:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726881AbgFQTxq (ORCPT ); Wed, 17 Jun 2020 15:53:46 -0400 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C695C06174E for ; Wed, 17 Jun 2020 12:53:44 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id m26so2044839lfo.13 for ; Wed, 17 Jun 2020 12:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=652Df2r0/DgKireW06s96KgNYOn5wGhQAsXaGuNmXIU=; b=u3Wa8m8AA+KUbrW2ZJpwKkh5OV+uw6/tbYieNTCpV+g/fKZMa/424dnXDq9k1pZPsC R3FzepNEt9eHmKEZLsQB6039RHnI2oLz4CeV+LIiyjsGAuVvKHjPqJBF3Os+Yu3DAD8h eayE3aq6KDW1uRolK2PO0BBU19aNm/+f0ZClqWN+6CBGWa1oZWt3Q1ccsHsxPC9fP8Fo fRbkAnztmRQIhCW37CvRuaE6qD0vU9+o9o/RIpz49UZIQk8W128R+KBu/KuSbu6ST/8e pUQ0WdEBLZ+YsiIPD892IivctXxTZsc2P7241Yy2nkAjGpLCkDQM5X2GbJvBqr2rZVAY UQQA== 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=652Df2r0/DgKireW06s96KgNYOn5wGhQAsXaGuNmXIU=; b=eYQbYx9EixTPWyjnRLHBr5DSd+u/9UQtKeSGHv8atIXOElVYoQwrwDlkIZF2jkt6yG NejLpO463eAdJzhBuR/lE7PYt4ZeUjr7oj+HfyGfBgzHR3sg+pU76DgzaTdWWV/ptEg7 sSPMnkt1GmCupBviT0mIk827BU1sDaN+pp5kULetr2Qk+HILTER3bHoGHt4pjefjqPOV P1bvpVnz0K+H+rouNHV5YwjjfRiBie/MtCElqHHjdR2TKFppEH5c6yt55tLa23kG3tCq +OTzhrukDXYP1ewkU0KMjEoSdbhz5bsM00624nmNs0zQNc9KzPvDoiG+x74tmxJ+WmHp pE3g== X-Gm-Message-State: AOAM532XEkcbpLVfMPiVYJeIp+0f7H/7KiHFOHiAnLPP7/XumxH+06Zc Io2Fb0otTc02SLix6QcSTbnCigrTpTgNhbzG0RMdjQ== X-Received: by 2002:ac2:41d4:: with SMTP id d20mr299095lfi.204.1592423622439; Wed, 17 Jun 2020 12:53:42 -0700 (PDT) MIME-Version: 1.0 References: <20200616011742.138975-1-rajatja@google.com> <20200616011742.138975-4-rajatja@google.com> <20200616073249.GB30385@infradead.org> <20200617073100.GA14424@infradead.org> In-Reply-To: <20200617073100.GA14424@infradead.org> From: Rajat Jain Date: Wed, 17 Jun 2020 12:53:03 -0700 Message-ID: Subject: Re: [PATCH 4/4] pci: export untrusted attribute in sysfs To: Christoph Hellwig Cc: David Woodhouse , Lu Baolu , Joerg Roedel , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown , iommu@lists.linux-foundation.org, Linux Kernel Mailing List , linux-pci , linux-acpi@vger.kernel.org, Raj Ashok , "Krishnakumar, Lalithambika" , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Rajat Jain , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , Greg Kroah-Hartman , "Oliver O'Halloran" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, Christoph, On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote: > > On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote: > > Need clarification. The flag "untrusted" is currently a part of > > pci_dev struct, and is populated within the PCI subsystem. > > Yes, and that is the problem. > > > > > 1) Is your suggestion to move this flag as well as the attribute to > > device core (in "struct device")? This would allow other buses to > > populate/use this flag if they want. By default it'll be set to 0 for > > all devices (PCI subsystem will populate it based on platform info, > > like it does today). > > > > OR > > > > 2) Are you suggesting to keep the "untrusted" flag within PCI, but > > attach the sysfs attribute to the base device? (&pci_dev->dev)? > > (1). As for IOMMUs and userspace policy it really should not matter > what bus a device is on if it is external and not trustworthy. Sure. I can move the flag to the "struct device" (and likely call it "external" instead of "untrusted" so as to make it suitable for more use cases later). The buses can fill this up if they know which devices are external and which ones are not (otherwise it will be 0 by default). The PCI can fill this up like it does today, from platform info (ACPI / Device tree). Greg, how does this sound? Thanks, Rajat