[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40d67b07-b56b-d626-f71b-54ef5c80275c@linux.intel.com>
Date: Thu, 23 Dec 2021 10:08:11 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
Alex Williamson <alex.williamson@...hat.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Jason Gunthorpe <jgg@...dia.com>,
Christoph Hellwig <hch@...radead.org>,
Kevin Tian <kevin.tian@...el.com>,
Ashok Raj <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Dan Williams <dan.j.williams@...el.com>, rafael@...nel.org,
Diana Craciun <diana.craciun@....nxp.com>,
Cornelia Huck <cohuck@...hat.com>,
Eric Auger <eric.auger@...hat.com>,
Liu Yi L <yi.l.liu@...el.com>,
Jacob jun Pan <jacob.jun.pan@...el.com>,
Chaitanya Kulkarni <kch@...dia.com>,
Stuart Yoder <stuyoder@...il.com>,
Laurentiu Tudor <laurentiu.tudor@....com>,
Thierry Reding <thierry.reding@...il.com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Jonathan Hunter <jonathanh@...dia.com>,
Li Yang <leoyang.li@....com>,
Dmitry Osipenko <digetx@...il.com>,
iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 02/13] driver core: Set DMA ownership during driver
bind/unbind
Hi Greg,
On 12/22/21 8:47 PM, Greg Kroah-Hartman wrote:
> Which one will actually care about the iommu_device_set_dma_owner()
> call? All of them? None of them? Some of them?
>
> Again, why can't this just happen in the (very few) bus callbacks that
> care about this? In following patches in this series, you turn off this
> for the pci_dma_configure users, so what is left? 3 odd bus types that
> are not used often. How well did you test devices of those types with
> this patchset?
>
> It's fine to have "suppress" fields when they are the minority, but here
> it's a_very_ tiny tiny number of actual devices in a system that will
> ever get the chance to have this check happen for them and trigger,
> right?
Thank you for your comments. Current VFIO implementation supports
devices on pci/platform/amba/fls-mc buses for user-space DMA. So only
those buses need to call iommu_device_set/release_dma_owner() in their
dma_configure/cleanup() callbacks.
The "suppress" field is only for a few device drivers (not devices), for
example,
- vfio-pci, a PCI device driver used to bind to a PCI device so that it
could be assigned for user-space DMA.
Other similar drivers in drivers/vfio are vfio-fsl-mc, vfio-amba and
vfio-platform. These drivers will call
iommu_device_set/release_dma_owner(DMA_OWNER_USER) explicitly when the
device is assigned to user.
The logic is that on the affected buses (pci/platform/amba/fls-mc),
- for non-vfio drivers, bus dma_configure/cleanup() will automatically
call iommu_device_set_dma_owner(KERNEL) for the device; [This is the
majority cases.]
- for vfio drivers, the auto-call will be suppressed, and the vfio
drivers are supposed to call iommu_device_set_dma_owner(USER) before
device is assigned to the userspace. [This is the rare case.]
The KERNEL and USER conflict will be detected in
iommu_device_set_dma_owner() with a -EBUSY return value. In that case,
the driver binding or device assignment should be aborted.
Best regards,
baolu
Powered by blists - more mailing lists