All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
	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>
Cc: Will Deacon <will@kernel.org>,
	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 v8 04/11] bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
Date: Tue, 8 Mar 2022 13:39:51 +0000	[thread overview]
Message-ID: <400b2dd3-120b-9728-3990-801b53447a2b@arm.com> (raw)
In-Reply-To: <20220308054421.847385-5-baolu.lu@linux.intel.com>

On 2022-03-08 05:44, Lu Baolu wrote:
> The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
> with the device DMA managed by kernel drivers or user-space applications.
> Unfortunately, multiple devices may be placed in the same IOMMU group
> because they cannot be isolated from each other. The DMA on these devices
> must either be entirely under kernel control or userspace control, never
> a mixture. Otherwise the driver integrity is not guaranteed because they
> could access each other through the peer-to-peer accesses which by-pass
> the IOMMU protection.
> 
> This checks and sets the default DMA mode during driver binding, and
> cleanups during driver unbinding. In the default mode, the device DMA is
> managed by the device driver which handles DMA operations through the
> kernel DMA APIs (see Documentation/core-api/dma-api.rst).
> 
> For cases where the devices are assigned for userspace control through the
> userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
> vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
> default setting in the assumption that the drivers know what they are
> doing with the device DMA.
> 
> Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
> is currently a problem. As things stand, the IOMMU driver ignored the
> initial iommu_probe_device() call when the device was added, since at
> that point it had no fwspec yet. In this situation,
> {of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
> the IOMMU driver has seen the firmware data via .of_xlate to learn that
> it actually responsible for the given device. As the result, before
> that gets fixed, iommu_use_default_domain() goes at the end, and calls
> arch_teardown_dma_ops() if it fails.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Stuart Yoder <stuyoder@gmail.com>
> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Lu Baolu <baolu.lu@linux.intel.com>,
	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>
Cc: Chaitanya Kulkarni <kch@nvidia.com>,
	kvm@vger.kernel.org, Stuart Yoder <stuyoder@gmail.com>,
	rafael@kernel.org, David Airlie <airlied@linux.ie>,
	linux-pci@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
	linux-kernel@vger.kernel.org,
	Jonathan Hunter <jonathanh@nvidia.com>,
	iommu@lists.linux-foundation.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Diana Craciun <diana.craciun@oss.nxp.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Li Yang <leoyang.li@nxp.com>, Will Deacon <will@kernel.org>,
	Dmitry Osipenko <digetx@gmail.com>
Subject: Re: [PATCH v8 04/11] bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
Date: Tue, 8 Mar 2022 13:39:51 +0000	[thread overview]
Message-ID: <400b2dd3-120b-9728-3990-801b53447a2b@arm.com> (raw)
In-Reply-To: <20220308054421.847385-5-baolu.lu@linux.intel.com>

On 2022-03-08 05:44, Lu Baolu wrote:
> The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
> with the device DMA managed by kernel drivers or user-space applications.
> Unfortunately, multiple devices may be placed in the same IOMMU group
> because they cannot be isolated from each other. The DMA on these devices
> must either be entirely under kernel control or userspace control, never
> a mixture. Otherwise the driver integrity is not guaranteed because they
> could access each other through the peer-to-peer accesses which by-pass
> the IOMMU protection.
> 
> This checks and sets the default DMA mode during driver binding, and
> cleanups during driver unbinding. In the default mode, the device DMA is
> managed by the device driver which handles DMA operations through the
> kernel DMA APIs (see Documentation/core-api/dma-api.rst).
> 
> For cases where the devices are assigned for userspace control through the
> userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
> vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
> default setting in the assumption that the drivers know what they are
> doing with the device DMA.
> 
> Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
> is currently a problem. As things stand, the IOMMU driver ignored the
> initial iommu_probe_device() call when the device was added, since at
> that point it had no fwspec yet. In this situation,
> {of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
> the IOMMU driver has seen the firmware data via .of_xlate to learn that
> it actually responsible for the given device. As the result, before
> that gets fixed, iommu_use_default_domain() goes at the end, and calls
> arch_teardown_dma_ops() if it fails.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Stuart Yoder <stuyoder@gmail.com>
> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Reviewed-by: Robin Murphy <robin.murphy@arm.com>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-03-08 13:40 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08  5:44 [PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2022-03-08  5:44 ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 01/11] iommu: Add DMA ownership management interfaces Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08 13:37   ` Robin Murphy
2022-03-08 13:37     ` Robin Murphy
2022-03-08  5:44 ` [PATCH v8 02/11] driver core: Add dma_cleanup callback in bus_type Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 03/11] amba: Stop sharing platform_dma_configure() Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 04/11] bus: platform, amba, fsl-mc, PCI: Add device DMA ownership management Lu Baolu
2022-03-08  5:44   ` [PATCH v8 04/11] bus: platform,amba,fsl-mc,PCI: " Lu Baolu
2022-03-08 13:39   ` Robin Murphy [this message]
2022-03-08 13:39     ` Robin Murphy
2022-03-08  5:44 ` [PATCH v8 05/11] PCI: pci_stub: Set driver_managed_dma Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 06/11] PCI: portdrv: " Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 07/11] vfio: Set DMA ownership for VFIO devices Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 08/11] vfio: Remove use of vfio_group_viable() Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 09/11] vfio: Delete the unbound_list Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 10/11] vfio: Remove iommu group notifier Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-08  5:44 ` [PATCH v8 11/11] iommu: Remove iommu group changes notifier Lu Baolu
2022-03-08  5:44   ` Lu Baolu
2022-03-10  9:46 ` [PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier() Eric Auger
2022-03-10  9:46   ` Eric Auger
2022-03-15  0:21 ` Jason Gunthorpe
2022-03-15  0:21   ` Jason Gunthorpe via iommu
2022-04-08  7:57   ` Joerg Roedel
2022-04-08  7:57     ` Joerg Roedel
2022-04-08 12:22     ` Lu Baolu
2022-04-08 12:22       ` Lu Baolu
2022-04-08 12:23       ` Jason Gunthorpe
2022-04-08 12:23         ` Jason Gunthorpe via iommu
2022-04-08 14:00         ` Joerg Roedel
2022-04-08 14:00           ` Joerg Roedel
2022-04-08 14:17           ` Jason Gunthorpe
2022-04-08 14:17             ` Jason Gunthorpe via iommu
2022-04-08 15:37             ` Joerg Roedel
2022-04-08 15:37               ` Joerg Roedel
2022-04-08 15:59               ` Bjorn Helgaas
2022-04-08 15:59                 ` Bjorn Helgaas
2022-04-08 16:07                 ` Alex Williamson
2022-04-08 16:07                   ` Alex Williamson
2022-04-08 20:24                   ` Jason Gunthorpe
2022-04-08 20:24                     ` Jason Gunthorpe via iommu

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=400b2dd3-120b-9728-3990-801b53447a2b@arm.com \
    --to=robin.murphy@arm.com \
    --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=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.