From: Bjorn Helgaas <helgaas@kernel.org> To: Lu Baolu <baolu.lu@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com>, Chaitanya Kulkarni <kch@nvidia.com>, Ashok Raj <ashok.raj@intel.com>, kvm@vger.kernel.org, rafael@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Cornelia Huck <cohuck@redhat.com>, linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Alex Williamson <alex.williamson@redhat.com>, Jacob jun Pan <jacob.jun.pan@intel.com>, Jason Gunthorpe <jgg@nvidia.com>, Diana Craciun <diana.craciun@oss.nxp.com>, Bjorn Helgaas <bhelgaas@google.com>, Will Deacon <will@kernel.org> Subject: Re: [PATCH 04/11] PCI: portdrv: Suppress kernel DMA ownership auto-claiming Date: Mon, 15 Nov 2021 14:44:59 -0600 [thread overview] Message-ID: <20211115204459.GA1585166@bhelgaas> (raw) In-Reply-To: <20211115020552.2378167-5-baolu.lu@linux.intel.com> On Mon, Nov 15, 2021 at 10:05:45AM +0800, Lu Baolu wrote: > IOMMU grouping on PCI necessitates that if we lack isolation on a bridge > then all of the downstream devices will be part of the same IOMMU group > as the bridge. I think this means something like: "If a PCIe Switch Downstream Port lacks <a specific set of ACS capabilities>, all downstream devices will be part of the same IOMMU group as the switch," right? If so, can you fill in the details to make it specific and concrete? > As long as the bridge kernel driver doesn't map and > access any PCI mmio bar, it's safe to bind it to the device in a USER- > owned group. Hence, safe to suppress the kernel DMA ownership auto- > claiming. s/mmio/MMIO/ (also below) s/bar/BAR/ (also below) I don't understand what "kernel DMA ownership auto-claiming" means. Presumably that's explained in previous patches and a code comment near "suppress_auto_claim_dma_owner". > The commit 5f096b14d421b ("vfio: Whitelist PCI bridges") permitted a > class of kernel drivers. Permitted them to do what? > This is not always safe. For example, the SHPC > system design requires that it must be integrated into a PCI-to-PCI > bridge or a host bridge. If this SHPC example is important, it would be nice to have a citation to the spec section that requires this. > The shpchp_core driver relies on the PCI mmio > bar access for the controller functionality. Binding it to the device > belonging to a USER-owned group will allow the user to change the > controller via p2p transactions which is unknown to the hot-plug driver > and could lead to some unpredictable consequences. > > Now that we have driver self-declaration of safety we should rely on that. Can you spell out what drivers are self-declaring? Are they declaring that they don't program their devices to do DMA? > This change may cause regression on some platforms, since all bridges were > exempted before, but now they have to be manually audited before doing so. > This is actually the desired outcome anyway. Please spell out what regression this may cause and how users would recognize it. Also, please give a hint about why that is desirable. > Suggested-by: Jason Gunthorpe <jgg@nvidia.com> > Suggested-by: Kevin Tian <kevin.tian@intel.com> > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/pci/pcie/portdrv_pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c > index 35eca6277a96..1285862a9aa8 100644 > --- a/drivers/pci/pcie/portdrv_pci.c > +++ b/drivers/pci/pcie/portdrv_pci.c > @@ -203,6 +203,8 @@ static struct pci_driver pcie_portdriver = { > .err_handler = &pcie_portdrv_err_handler, > > .driver.pm = PCIE_PORTDRV_PM_OPS, > + > + .driver.suppress_auto_claim_dma_owner = true, > }; > > static int __init dmi_pcie_pme_disable_msi(const struct dmi_system_id *d) > -- > 2.25.1 > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
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>, Kevin Tian <kevin.tian@intel.com>, Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>, 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>, iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 04/11] PCI: portdrv: Suppress kernel DMA ownership auto-claiming Date: Mon, 15 Nov 2021 14:44:59 -0600 [thread overview] Message-ID: <20211115204459.GA1585166@bhelgaas> (raw) In-Reply-To: <20211115020552.2378167-5-baolu.lu@linux.intel.com> On Mon, Nov 15, 2021 at 10:05:45AM +0800, Lu Baolu wrote: > IOMMU grouping on PCI necessitates that if we lack isolation on a bridge > then all of the downstream devices will be part of the same IOMMU group > as the bridge. I think this means something like: "If a PCIe Switch Downstream Port lacks <a specific set of ACS capabilities>, all downstream devices will be part of the same IOMMU group as the switch," right? If so, can you fill in the details to make it specific and concrete? > As long as the bridge kernel driver doesn't map and > access any PCI mmio bar, it's safe to bind it to the device in a USER- > owned group. Hence, safe to suppress the kernel DMA ownership auto- > claiming. s/mmio/MMIO/ (also below) s/bar/BAR/ (also below) I don't understand what "kernel DMA ownership auto-claiming" means. Presumably that's explained in previous patches and a code comment near "suppress_auto_claim_dma_owner". > The commit 5f096b14d421b ("vfio: Whitelist PCI bridges") permitted a > class of kernel drivers. Permitted them to do what? > This is not always safe. For example, the SHPC > system design requires that it must be integrated into a PCI-to-PCI > bridge or a host bridge. If this SHPC example is important, it would be nice to have a citation to the spec section that requires this. > The shpchp_core driver relies on the PCI mmio > bar access for the controller functionality. Binding it to the device > belonging to a USER-owned group will allow the user to change the > controller via p2p transactions which is unknown to the hot-plug driver > and could lead to some unpredictable consequences. > > Now that we have driver self-declaration of safety we should rely on that. Can you spell out what drivers are self-declaring? Are they declaring that they don't program their devices to do DMA? > This change may cause regression on some platforms, since all bridges were > exempted before, but now they have to be manually audited before doing so. > This is actually the desired outcome anyway. Please spell out what regression this may cause and how users would recognize it. Also, please give a hint about why that is desirable. > Suggested-by: Jason Gunthorpe <jgg@nvidia.com> > Suggested-by: Kevin Tian <kevin.tian@intel.com> > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/pci/pcie/portdrv_pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c > index 35eca6277a96..1285862a9aa8 100644 > --- a/drivers/pci/pcie/portdrv_pci.c > +++ b/drivers/pci/pcie/portdrv_pci.c > @@ -203,6 +203,8 @@ static struct pci_driver pcie_portdriver = { > .err_handler = &pcie_portdrv_err_handler, > > .driver.pm = PCIE_PORTDRV_PM_OPS, > + > + .driver.suppress_auto_claim_dma_owner = true, > }; > > static int __init dmi_pcie_pme_disable_msi(const struct dmi_system_id *d) > -- > 2.25.1 >
next prev parent reply other threads:[~2021-11-15 20:45 UTC|newest] Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-15 2:05 [PATCH 00/11] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 01/11] iommu: Add device dma ownership set/release interfaces Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 13:14 ` Christoph Hellwig 2021-11-15 13:14 ` Christoph Hellwig 2021-11-16 1:57 ` Lu Baolu 2021-11-16 1:57 ` Lu Baolu 2021-11-16 13:46 ` Jason Gunthorpe 2021-11-16 13:46 ` Jason Gunthorpe via iommu 2021-11-17 5:22 ` Lu Baolu 2021-11-17 5:22 ` Lu Baolu 2021-11-17 13:35 ` Jason Gunthorpe 2021-11-17 13:35 ` Jason Gunthorpe via iommu 2021-11-18 1:12 ` Lu Baolu 2021-11-18 1:12 ` Lu Baolu 2021-11-18 14:10 ` Jason Gunthorpe 2021-11-18 14:10 ` Jason Gunthorpe via iommu 2021-11-18 2:39 ` Tian, Kevin 2021-11-18 2:39 ` Tian, Kevin 2021-11-18 13:33 ` Jason Gunthorpe 2021-11-18 13:33 ` Jason Gunthorpe via iommu 2021-11-19 5:44 ` Tian, Kevin 2021-11-19 5:44 ` Tian, Kevin 2021-11-19 11:14 ` Lu Baolu 2021-11-19 11:14 ` Lu Baolu 2021-11-19 15:06 ` Jörg Rödel 2021-11-19 15:06 ` Jörg Rödel 2021-11-19 15:43 ` Jason Gunthorpe 2021-11-19 15:43 ` Jason Gunthorpe via iommu 2021-11-20 11:16 ` Lu Baolu 2021-11-20 11:16 ` Lu Baolu 2021-11-19 12:56 ` Jason Gunthorpe 2021-11-19 12:56 ` Jason Gunthorpe via iommu 2021-11-15 20:38 ` Bjorn Helgaas 2021-11-15 20:38 ` Bjorn Helgaas 2021-11-16 1:52 ` Lu Baolu 2021-11-16 1:52 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 6:59 ` Greg Kroah-Hartman 2021-11-15 6:59 ` Greg Kroah-Hartman 2021-11-15 13:20 ` Christoph Hellwig 2021-11-15 13:20 ` Christoph Hellwig 2021-11-15 13:38 ` Jason Gunthorpe via iommu 2021-11-15 13:38 ` Jason Gunthorpe 2021-11-15 13:19 ` Christoph Hellwig 2021-11-15 13:19 ` Christoph Hellwig 2021-11-15 13:24 ` Jason Gunthorpe 2021-11-15 13:24 ` Jason Gunthorpe via iommu 2021-11-15 15:37 ` Robin Murphy 2021-11-15 15:37 ` Robin Murphy 2021-11-15 15:56 ` Jason Gunthorpe 2021-11-15 15:56 ` Jason Gunthorpe via iommu 2021-11-15 18:15 ` Christoph Hellwig 2021-11-15 18:15 ` Christoph Hellwig 2021-11-15 18:35 ` Robin Murphy 2021-11-15 18:35 ` Robin Murphy 2021-11-15 19:39 ` Jason Gunthorpe via iommu 2021-11-15 19:39 ` Jason Gunthorpe 2021-11-15 2:05 ` [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 13:21 ` Christoph Hellwig 2021-11-15 13:21 ` Christoph Hellwig 2021-11-15 13:31 ` Jason Gunthorpe via iommu 2021-11-15 13:31 ` Jason Gunthorpe 2021-11-15 15:14 ` Robin Murphy 2021-11-15 15:14 ` Robin Murphy 2021-11-15 16:17 ` Jason Gunthorpe 2021-11-15 16:17 ` Jason Gunthorpe via iommu 2021-11-15 17:54 ` Robin Murphy 2021-11-15 17:54 ` Robin Murphy 2021-11-15 18:19 ` Christoph Hellwig 2021-11-15 18:19 ` Christoph Hellwig 2021-11-15 18:44 ` Robin Murphy 2021-11-15 18:44 ` Robin Murphy 2021-11-15 19:22 ` Jason Gunthorpe via iommu 2021-11-15 19:22 ` Jason Gunthorpe 2021-11-15 20:58 ` Robin Murphy 2021-11-15 20:58 ` Robin Murphy 2021-11-15 21:19 ` Jason Gunthorpe via iommu 2021-11-15 21:19 ` Jason Gunthorpe 2021-11-15 20:48 ` Bjorn Helgaas 2021-11-15 20:48 ` Bjorn Helgaas 2021-11-15 22:17 ` Bjorn Helgaas 2021-11-15 22:17 ` Bjorn Helgaas 2021-11-16 6:05 ` Lu Baolu 2021-11-16 6:05 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 04/11] PCI: portdrv: " Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 20:44 ` Bjorn Helgaas [this message] 2021-11-15 20:44 ` Bjorn Helgaas 2021-11-16 7:24 ` Lu Baolu 2021-11-16 7:24 ` Lu Baolu 2021-11-16 20:22 ` Bjorn Helgaas 2021-11-16 20:22 ` Bjorn Helgaas 2021-11-16 20:48 ` Jason Gunthorpe 2021-11-16 20:48 ` Jason Gunthorpe via iommu 2021-11-15 2:05 ` [PATCH 05/11] iommu: Add security context management for assigned devices Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 13:22 ` Christoph Hellwig 2021-11-15 13:22 ` Christoph Hellwig 2021-11-16 7:25 ` Lu Baolu 2021-11-16 7:25 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 06/11] iommu: Expose group variants of dma ownership interfaces Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 13:27 ` Christoph Hellwig 2021-11-15 13:27 ` Christoph Hellwig 2021-11-16 9:42 ` Lu Baolu 2021-11-16 9:42 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 07/11] vfio: Use DMA_OWNER_USER to declaim passthrough devices Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 08/11] vfio: Remove use of vfio_group_viable() Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 09/11] vfio: Delete the unbound_list Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 10/11] vfio: Remove iommu group notifier Lu Baolu 2021-11-15 2:05 ` Lu Baolu 2021-11-15 2:05 ` [PATCH 11/11] iommu: Remove iommu group changes notifier Lu Baolu 2021-11-15 2:05 ` 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=20211115204459.GA1585166@bhelgaas \ --to=helgaas@kernel.org \ --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=diana.craciun@oss.nxp.com \ --cc=gregkh@linuxfoundation.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@intel.com \ --cc=jgg@nvidia.com \ --cc=kch@nvidia.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=rafael@kernel.org \ --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: linkBe 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.