All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Dan Williams <dan.j.williams@intel.com>,
	rafael@kernel.org, Diana Craciun <diana.craciun@oss.nxp.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Stuart Yoder <stuyoder@gmail.com>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Li Yang <leoyang.li@nxp.com>, Dmitry Osipenko <digetx@gmail.com>,
	iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 09/14] PCI: portdrv: Suppress kernel DMA ownership auto-claiming
Date: Thu, 6 Jan 2022 12:32:24 -0600	[thread overview]
Message-ID: <20220106183224.GA298861@bhelgaas> (raw)
In-Reply-To: <039bbcf3-ccc6-f3b0-172e-9caa0866bb9e@linux.intel.com>

On Thu, Jan 06, 2022 at 12:12:35PM +0800, Lu Baolu wrote:
> On 1/5/22 1:06 AM, Bjorn Helgaas wrote:
> > On Tue, Jan 04, 2022 at 09:56:39AM +0800, Lu Baolu wrote:
> > > If a switch lacks ACS P2P Request Redirect, a device below the switch can
> > > bypass the IOMMU and DMA directly to other devices below the switch, so
> > > all the downstream devices must be in the same IOMMU group as the switch
> > > itself.
> > Help me think through what's going on here.  IIUC, we put devices in
> > the same IOMMU group when they can interfere with each other in any
> > way (DMA, config access, etc).
> > 
> > (We said "DMA" above, but I guess this would also apply to config
> > requests, right?)
> 
> I am not sure whether devices could interfere each other through config
> space access. The IOMMU hardware only protects and isolates DMA
> accesses, so that userspace could control DMA directly. The config
> accesses will always be intercepted by VFIO. Hence, I don't see a
> problem.

I was wondering about config accesses generated by an endpoint, e.g.,
an endpoint doing config writes to a peer or the upstream bridge.

But I think that is prohibited by spec - PCIe r5.0, sec 7.3.3, says
"Propagation of Configuration Requests from Downstream to Upstream as
well as peer-to-peer are not supported" and "Configuration Requests
are initiated only by the Host Bridge, including those passed through
the SFI CAM mechanism."

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Stuart Yoder <stuyoder@gmail.com>,
	rafael@kernel.org, David Airlie <airlied@linux.ie>,
	linux-pci@vger.kernel.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Diana Craciun <diana.craciun@oss.nxp.com>,
	Dmitry Osipenko <digetx@gmail.com>, Will Deacon <will@kernel.org>,
	Ashok Raj <ashok.raj@intel.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Christoph Hellwig <hch@infradead.org>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cornelia Huck <cohuck@redhat.com>,
	linux-kernel@vger.kernel.org, Li Yang <leoyang.li@nxp.com>,
	iommu@lists.linux-foundation.org,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v5 09/14] PCI: portdrv: Suppress kernel DMA ownership auto-claiming
Date: Thu, 6 Jan 2022 12:32:24 -0600	[thread overview]
Message-ID: <20220106183224.GA298861@bhelgaas> (raw)
In-Reply-To: <039bbcf3-ccc6-f3b0-172e-9caa0866bb9e@linux.intel.com>

On Thu, Jan 06, 2022 at 12:12:35PM +0800, Lu Baolu wrote:
> On 1/5/22 1:06 AM, Bjorn Helgaas wrote:
> > On Tue, Jan 04, 2022 at 09:56:39AM +0800, Lu Baolu wrote:
> > > If a switch lacks ACS P2P Request Redirect, a device below the switch can
> > > bypass the IOMMU and DMA directly to other devices below the switch, so
> > > all the downstream devices must be in the same IOMMU group as the switch
> > > itself.
> > Help me think through what's going on here.  IIUC, we put devices in
> > the same IOMMU group when they can interfere with each other in any
> > way (DMA, config access, etc).
> > 
> > (We said "DMA" above, but I guess this would also apply to config
> > requests, right?)
> 
> I am not sure whether devices could interfere each other through config
> space access. The IOMMU hardware only protects and isolates DMA
> accesses, so that userspace could control DMA directly. The config
> accesses will always be intercepted by VFIO. Hence, I don't see a
> problem.

I was wondering about config accesses generated by an endpoint, e.g.,
an endpoint doing config writes to a peer or the upstream bridge.

But I think that is prohibited by spec - PCIe r5.0, sec 7.3.3, says
"Propagation of Configuration Requests from Downstream to Upstream as
well as peer-to-peer are not supported" and "Configuration Requests
are initiated only by the Host Bridge, including those passed through
the SFI CAM mechanism."

Bjorn
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-01-06 18:32 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04  1:56 [PATCH v5 00/14] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2022-01-04  1:56 ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 01/14] iommu: Add dma ownership management interfaces Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 10:08   ` Christoph Hellwig
2022-01-04 10:08     ` Christoph Hellwig
2022-01-04 16:41     ` Bjorn Helgaas
2022-01-04 16:41       ` Bjorn Helgaas
2022-01-04 19:23       ` Jason Gunthorpe
2022-01-04 19:23         ` Jason Gunthorpe via iommu
2022-01-06  3:18         ` Lu Baolu
2022-01-06  3:18           ` Lu Baolu
2022-01-06  3:54         ` Lu Baolu
2022-01-06  3:54           ` Lu Baolu
2022-01-06 15:46           ` Jason Gunthorpe
2022-01-06 15:46             ` Jason Gunthorpe via iommu
2022-01-07  1:50             ` Lu Baolu
2022-01-07  1:50               ` Lu Baolu
2022-01-06  3:43       ` Lu Baolu
2022-01-06  3:43         ` Lu Baolu
2022-01-06  3:47       ` Lu Baolu
2022-01-06  3:47         ` Lu Baolu
2022-01-06  3:51       ` Lu Baolu
2022-01-06  3:51         ` Lu Baolu
2022-01-05  6:57     ` Lu Baolu
2022-01-05  6:57       ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 02/14] driver core: Add dma_cleanup callback in bus_type Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 10:08   ` Christoph Hellwig
2022-01-04 10:08     ` Christoph Hellwig
2022-01-04 12:39     ` Jason Gunthorpe
2022-01-04 12:39       ` Jason Gunthorpe via iommu
2022-01-04 13:04       ` Greg Kroah-Hartman
2022-01-04 13:04         ` Greg Kroah-Hartman
2022-02-08  5:55         ` Lu Baolu
2022-02-08  5:55           ` Lu Baolu
2022-02-08 11:35           ` Greg Kroah-Hartman
2022-02-08 11:35             ` Greg Kroah-Hartman
2022-02-14 10:01     ` Greg Kroah-Hartman
2022-02-14 10:01       ` Greg Kroah-Hartman
2022-02-14 10:02   ` Greg Kroah-Hartman
2022-02-14 10:02     ` Greg Kroah-Hartman
2022-01-04  1:56 ` [PATCH v5 03/14] amba: Stop sharing platform_dma_configure() Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 04/14] driver core: platform: Add driver dma ownership management Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-02-14  9:59   ` Greg Kroah-Hartman
2022-02-14  9:59     ` Greg Kroah-Hartman
2022-02-14 13:18     ` Jason Gunthorpe
2022-02-14 13:18       ` Jason Gunthorpe via iommu
2022-02-14 13:37       ` Greg Kroah-Hartman
2022-02-14 13:37         ` Greg Kroah-Hartman
2022-02-14 13:43         ` Jason Gunthorpe
2022-02-14 13:43           ` Jason Gunthorpe via iommu
2022-01-04  1:56 ` [PATCH v5 05/14] amba: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 06/14] bus: fsl-mc: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 07/14] PCI: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-02-14 10:03   ` Greg Kroah-Hartman
2022-02-14 10:03     ` Greg Kroah-Hartman
2022-02-14 12:38     ` Jason Gunthorpe
2022-02-14 12:38       ` Jason Gunthorpe via iommu
2022-02-14 12:51       ` Greg Kroah-Hartman
2022-02-14 12:51         ` Greg Kroah-Hartman
2022-02-14 13:11         ` Jason Gunthorpe
2022-02-14 13:11           ` Jason Gunthorpe via iommu
2022-02-14 13:39           ` Greg Kroah-Hartman
2022-02-14 13:39             ` Greg Kroah-Hartman
2022-02-14 13:43             ` Jason Gunthorpe
2022-02-14 13:43               ` Jason Gunthorpe via iommu
2022-02-15  3:06               ` Lu Baolu
2022-02-15  3:06                 ` Lu Baolu
2022-02-23 18:00   ` Bjorn Helgaas
2022-02-23 18:00     ` Bjorn Helgaas
2022-02-23 18:07     ` Jason Gunthorpe
2022-02-23 18:07       ` Jason Gunthorpe via iommu
2022-01-04  1:56 ` [PATCH v5 08/14] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 09/14] PCI: portdrv: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 17:06   ` Bjorn Helgaas
2022-01-04 17:06     ` Bjorn Helgaas
2022-01-04 19:26     ` Jason Gunthorpe
2022-01-04 19:26       ` Jason Gunthorpe via iommu
2022-01-04 19:51       ` Bjorn Helgaas
2022-01-04 19:51         ` Bjorn Helgaas
2022-01-05  0:35         ` Jason Gunthorpe
2022-01-05  0:35           ` Jason Gunthorpe via iommu
2022-01-06  4:12     ` Lu Baolu
2022-01-06  4:12       ` Lu Baolu
2022-01-06 18:32       ` Bjorn Helgaas [this message]
2022-01-06 18:32         ` Bjorn Helgaas
2022-01-07  1:53         ` Lu Baolu
2022-01-07  1:53           ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 10/14] vfio: Set DMA ownership for VFIO devices Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 11/14] vfio: Remove use of vfio_group_viable() Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 12/14] vfio: Delete the unbound_list Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 13/14] vfio: Remove iommu group notifier Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 14/14] iommu: Remove iommu group changes notifier Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 12:48 ` [PATCH v5 00/14] Fix BUG_ON in vfio_iommu_group_notifier() Jason Gunthorpe
2022-01-04 12:48   ` Jason Gunthorpe via iommu
2022-01-05  6:52   ` Lu Baolu
2022-01-05  6:52     ` Lu Baolu
2022-02-18  1:07 ` Lu Baolu
2022-02-18  1:07   ` Lu Baolu

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=20220106183224.GA298861@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=airlied@linux.ie \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=cohuck@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=diana.craciun@oss.nxp.com \
    --cc=digetx@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kch@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=laurentiu.tudor@nxp.com \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stuyoder@gmail.com \
    --cc=thierry.reding@gmail.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.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.