From: Bjorn Helgaas <helgaas@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Rajat Jain <rajatja@google.com>, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, rajatxjain@gmail.com
Subject: Re: [PATCH] pci: Rename pci_dev->untrusted to pci_dev->external
Date: Tue, 20 Apr 2021 12:07:08 -0500 [thread overview]
Message-ID: <20210420170708.GA2813156@bjorn-Precision-5520> (raw)
In-Reply-To: <20210420061006.GA3523612@infradead.org>
On Tue, Apr 20, 2021 at 07:10:06AM +0100, Christoph Hellwig wrote:
> On Mon, Apr 19, 2021 at 05:30:49PM -0700, Rajat Jain wrote:
> > The current flag name "untrusted" is not correct as it is populated
> > using the firmware property "external-facing" for the parent ports. In
> > other words, the firmware only says which ports are external facing, so
> > the field really identifies the devices as external (vs internal).
> >
> > Only field renaming. No functional change intended.
>
> I don't think this is a good idea. First the field should have been
> added to the generic struct device as requested multiple times before.
Fair point. There isn't anything PCI-specific about this idea. The
ACPI "ExternalFacingPort" and DT "external-facing" are currently only
defined for PCI devices, but could be applied elsewhere.
> Right now this requires horrible hacks in the IOMMU code to get at the
> pci_dev, and also doesn't scale to various other potential users.
Agreed, this is definitely suboptimal. Do you have other users in
mind? Maybe they could help inform the plan.
> Second the untrusted is objectively a better name. Because untrusted
> is how we treat the device, which is what mattes. External is just
> how we come to that conclusion.
The decision to treat "external" as being "untrusted" is a little bit
of policy that the PCI core really doesn't care about, so I think it
does make some sense to let the places that *do* care decide what to
trust based on "external" and possibly other factors, e.g., whether
the device is a BMC or processes untrusted data, etc.
But I guess it makes sense to wait until we have a better motivation
before renaming it, since we don't gain any functionality here.
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: rajatxjain@gmail.com, Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Rajat Jain <rajatja@google.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] pci: Rename pci_dev->untrusted to pci_dev->external
Date: Tue, 20 Apr 2021 12:07:08 -0500 [thread overview]
Message-ID: <20210420170708.GA2813156@bjorn-Precision-5520> (raw)
In-Reply-To: <20210420061006.GA3523612@infradead.org>
On Tue, Apr 20, 2021 at 07:10:06AM +0100, Christoph Hellwig wrote:
> On Mon, Apr 19, 2021 at 05:30:49PM -0700, Rajat Jain wrote:
> > The current flag name "untrusted" is not correct as it is populated
> > using the firmware property "external-facing" for the parent ports. In
> > other words, the firmware only says which ports are external facing, so
> > the field really identifies the devices as external (vs internal).
> >
> > Only field renaming. No functional change intended.
>
> I don't think this is a good idea. First the field should have been
> added to the generic struct device as requested multiple times before.
Fair point. There isn't anything PCI-specific about this idea. The
ACPI "ExternalFacingPort" and DT "external-facing" are currently only
defined for PCI devices, but could be applied elsewhere.
> Right now this requires horrible hacks in the IOMMU code to get at the
> pci_dev, and also doesn't scale to various other potential users.
Agreed, this is definitely suboptimal. Do you have other users in
mind? Maybe they could help inform the plan.
> Second the untrusted is objectively a better name. Because untrusted
> is how we treat the device, which is what mattes. External is just
> how we come to that conclusion.
The decision to treat "external" as being "untrusted" is a little bit
of policy that the PCI core really doesn't care about, so I think it
does make some sense to let the places that *do* care decide what to
trust based on "external" and possibly other factors, e.g., whether
the device is a BMC or processes untrusted data, etc.
But I guess it makes sense to wait until we have a better motivation
before renaming it, since we don't gain any functionality here.
Bjorn
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-04-20 17:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-20 0:30 [PATCH] pci: Rename pci_dev->untrusted to pci_dev->external Rajat Jain
2021-04-20 0:30 ` Rajat Jain via iommu
2021-04-20 6:10 ` Christoph Hellwig
2021-04-20 6:10 ` Christoph Hellwig
2021-04-20 17:07 ` Bjorn Helgaas [this message]
2021-04-20 17:07 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210420170708.GA2813156@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rajatja@google.com \
--cc=rajatxjain@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.