All of lore.kernel.org
 help / color / mirror / Atom feed
From: "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "michael.jamet@intel.com" <michael.jamet@intel.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"YehezkelShB@gmail.com" <YehezkelShB@gmail.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"Limonciello, Mario" <Mario.Limonciello@amd.com>,
	"andreas.noever@gmail.com" <andreas.noever@gmail.com>
Subject: Re: [PATCH] thunderbolt: Make iommu_dma_protection more accurate
Date: Fri, 18 Mar 2022 17:23:45 +0200	[thread overview]
Message-ID: <YjSkAcxLDFmVdhEq@lahna> (raw)
In-Reply-To: <73e25ee3-c2f3-0a72-e5cc-04e51f650f2e@arm.com>

Hi Robin,

On Fri, Mar 18, 2022 at 03:15:19PM +0000, Robin Murphy wrote:
> > IMHO we should just trust the firmare provided information here
> > (otherwise we are screwed anyway as there is no way to tell if the
> > devices connected prior the OS can still do DMA), and use the external
> > facing port indicator to idenfity the ports that need DMA protection.
> 
> Indeed that's exactly what I want to do, but it begs the question of how we
> *find* the firmware-provided information in the first place!

Oh, right :) Its the combination of ACPI _DSD "ExternalFacingPort"
(which we already set, dev->external_facing, dev->untrusted for the
devices behind these ports IIRC) and the DMAR opt-in bit. All these are
already read by the kernel.

> I seem to have already started writing the dumb version that will walk the
> whole PCI segment and assume the presence of any external-facing port
> implies that we're good. Let me know if I should stop ;)

That sounds good to me, so don't stop just yet ;-)
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>,
	"andreas.noever@gmail.com" <andreas.noever@gmail.com>,
	"michael.jamet@intel.com" <michael.jamet@intel.com>,
	"YehezkelShB@gmail.com" <YehezkelShB@gmail.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] thunderbolt: Make iommu_dma_protection more accurate
Date: Fri, 18 Mar 2022 17:23:45 +0200	[thread overview]
Message-ID: <YjSkAcxLDFmVdhEq@lahna> (raw)
In-Reply-To: <73e25ee3-c2f3-0a72-e5cc-04e51f650f2e@arm.com>

Hi Robin,

On Fri, Mar 18, 2022 at 03:15:19PM +0000, Robin Murphy wrote:
> > IMHO we should just trust the firmare provided information here
> > (otherwise we are screwed anyway as there is no way to tell if the
> > devices connected prior the OS can still do DMA), and use the external
> > facing port indicator to idenfity the ports that need DMA protection.
> 
> Indeed that's exactly what I want to do, but it begs the question of how we
> *find* the firmware-provided information in the first place!

Oh, right :) Its the combination of ACPI _DSD "ExternalFacingPort"
(which we already set, dev->external_facing, dev->untrusted for the
devices behind these ports IIRC) and the DMAR opt-in bit. All these are
already read by the kernel.

> I seem to have already started writing the dumb version that will walk the
> whole PCI segment and assume the presence of any external-facing port
> implies that we're good. Let me know if I should stop ;)

That sounds good to me, so don't stop just yet ;-)

  reply	other threads:[~2022-03-18 15:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 16:17 [PATCH] thunderbolt: Make iommu_dma_protection more accurate Robin Murphy
2022-03-17 16:17 ` Robin Murphy
2022-03-17 16:58 ` Greg KH
2022-03-17 16:58   ` Greg KH
2022-03-17 17:09 ` Limonciello, Mario via iommu
2022-03-17 17:09   ` Limonciello, Mario
2022-03-17 20:36   ` Limonciello, Mario via iommu
2022-03-17 20:36     ` Limonciello, Mario
2022-03-18 11:38     ` mika.westerberg
2022-03-18 11:38       ` mika.westerberg
2022-03-18 12:01       ` Robin Murphy
2022-03-18 12:01         ` Robin Murphy
2022-03-18 13:25         ` mika.westerberg
2022-03-18 13:25           ` mika.westerberg
2022-03-18 14:08           ` Robin Murphy
2022-03-18 14:08             ` Robin Murphy
2022-03-18 14:22             ` Limonciello, Mario via iommu
2022-03-18 14:22               ` Limonciello, Mario
2022-03-18 14:47             ` mika.westerberg
2022-03-18 14:47               ` mika.westerberg
2022-03-18 15:15               ` Robin Murphy
2022-03-18 15:15                 ` Robin Murphy
2022-03-18 15:23                 ` mika.westerberg [this message]
2022-03-18 15:23                   ` mika.westerberg
2022-03-18 14:51             ` Lukas Wunner
2022-03-18 14:51               ` Lukas Wunner
2022-03-18 15:10               ` Lukas Wunner
2022-03-18 15:10                 ` Lukas Wunner
2022-03-18 15:11               ` mika.westerberg
2022-03-18 15:11                 ` mika.westerberg
2022-03-18  6:44 ` Mika Westerberg
2022-03-18  6:44   ` Mika Westerberg
2022-03-18 11:54   ` Robin Murphy
2022-03-18 11:54     ` Robin Murphy

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=YjSkAcxLDFmVdhEq@lahna \
    --to=mika.westerberg@linux.intel.com \
    --cc=Mario.Limonciello@amd.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=michael.jamet@intel.com \
    --cc=robin.murphy@arm.com \
    /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.