From: Lu Baolu <baolu.lu@linux.intel.com> To: Bjorn Helgaas <helgaas@kernel.org> 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 01/11] iommu: Add device dma ownership set/release interfaces Date: Tue, 16 Nov 2021 09:52:49 +0800 [thread overview] Message-ID: <6a2e3d54-8c7f-0367-081b-5448d93f5ca5@linux.intel.com> (raw) In-Reply-To: <20211115203848.GA1586192@bhelgaas> Hi Bjorn, On 11/16/21 4:38 AM, Bjorn Helgaas wrote: > On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote: >> From the perspective of who is initiating the device to do DMA, device >> DMA could be divided into the following types: >> >> DMA_OWNER_KERNEL: kernel device driver intiates the DMA >> DMA_OWNER_USER: userspace device driver intiates the DMA > > s/intiates/initiates/ (twice) Yes. > > As your first sentence suggests, the driver doesn't actually > *initiate* the DMA in either case. One of the drivers programs the > device, and the *device* initiates the DMA. You are right. I could rephrase it as: "From the perspective of who is controlling the device to do DMA ..." > >> DMA_OWNER_KERNEL and DMA_OWNER_USER are exclusive for all devices in >> same iommu group as an iommu group is the smallest granularity of device >> isolation and protection that the IOMMU subsystem can guarantee. > > I think this basically says DMA_OWNER_KERNEL and DMA_OWNER_USER are > attributes of the iommu_group (not an individual device), and it > applies to all devices in the iommu_group. Below, you allude to the > fact that the interfaces are per-device. It's not clear to me why you > made a per-device interface instead of a per-group interface. Yes, the attributes are of the iommu_group. We have both per-device and per-iommu_group interfaces. The former is for device drivers and the latter is only for vfio who has an iommu_group based iommu abstract. >> This >> extends the iommu core to enforce this exclusion when devices are >> assigned to userspace. >> >> Basically two new interfaces are provided: >> >> int iommu_device_set_dma_owner(struct device *dev, >> enum iommu_dma_owner mode, struct file *user_file); >> void iommu_device_release_dma_owner(struct device *dev, >> enum iommu_dma_owner mode); >> >> Although above interfaces are per-device, DMA owner is tracked per group >> under the hood. An iommu group cannot have both DMA_OWNER_KERNEL >> and DMA_OWNER_USER set at the same time. Violation of this assumption >> fails iommu_device_set_dma_owner(). >> >> Kernel driver which does DMA have DMA_OWNER_KENREL automatically >> set/released in the driver binding process (see next patch). > > s/DMA_OWNER_KENREL/DMA_OWNER_KERNEL/ Yes. Sorry for the typo. > >> Kernel driver which doesn't do DMA should not set the owner type (via a >> new suppress flag in next patch). Device bound to such driver is considered >> same as a driver-less device which is compatible to all owner types. >> >> Userspace driver framework (e.g. vfio) should set DMA_OWNER_USER for >> a device before the userspace is allowed to access it, plus a fd pointer to >> mark the user identity so a single group cannot be operated by multiple >> users simultaneously. Vice versa, the owner type should be released after >> the user access permission is withdrawn. Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com> To: Bjorn Helgaas <helgaas@kernel.org> Cc: 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>, 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 01/11] iommu: Add device dma ownership set/release interfaces Date: Tue, 16 Nov 2021 09:52:49 +0800 [thread overview] Message-ID: <6a2e3d54-8c7f-0367-081b-5448d93f5ca5@linux.intel.com> (raw) In-Reply-To: <20211115203848.GA1586192@bhelgaas> Hi Bjorn, On 11/16/21 4:38 AM, Bjorn Helgaas wrote: > On Mon, Nov 15, 2021 at 10:05:42AM +0800, Lu Baolu wrote: >> From the perspective of who is initiating the device to do DMA, device >> DMA could be divided into the following types: >> >> DMA_OWNER_KERNEL: kernel device driver intiates the DMA >> DMA_OWNER_USER: userspace device driver intiates the DMA > > s/intiates/initiates/ (twice) Yes. > > As your first sentence suggests, the driver doesn't actually > *initiate* the DMA in either case. One of the drivers programs the > device, and the *device* initiates the DMA. You are right. I could rephrase it as: "From the perspective of who is controlling the device to do DMA ..." > >> DMA_OWNER_KERNEL and DMA_OWNER_USER are exclusive for all devices in >> same iommu group as an iommu group is the smallest granularity of device >> isolation and protection that the IOMMU subsystem can guarantee. > > I think this basically says DMA_OWNER_KERNEL and DMA_OWNER_USER are > attributes of the iommu_group (not an individual device), and it > applies to all devices in the iommu_group. Below, you allude to the > fact that the interfaces are per-device. It's not clear to me why you > made a per-device interface instead of a per-group interface. Yes, the attributes are of the iommu_group. We have both per-device and per-iommu_group interfaces. The former is for device drivers and the latter is only for vfio who has an iommu_group based iommu abstract. >> This >> extends the iommu core to enforce this exclusion when devices are >> assigned to userspace. >> >> Basically two new interfaces are provided: >> >> int iommu_device_set_dma_owner(struct device *dev, >> enum iommu_dma_owner mode, struct file *user_file); >> void iommu_device_release_dma_owner(struct device *dev, >> enum iommu_dma_owner mode); >> >> Although above interfaces are per-device, DMA owner is tracked per group >> under the hood. An iommu group cannot have both DMA_OWNER_KERNEL >> and DMA_OWNER_USER set at the same time. Violation of this assumption >> fails iommu_device_set_dma_owner(). >> >> Kernel driver which does DMA have DMA_OWNER_KENREL automatically >> set/released in the driver binding process (see next patch). > > s/DMA_OWNER_KENREL/DMA_OWNER_KERNEL/ Yes. Sorry for the typo. > >> Kernel driver which doesn't do DMA should not set the owner type (via a >> new suppress flag in next patch). Device bound to such driver is considered >> same as a driver-less device which is compatible to all owner types. >> >> Userspace driver framework (e.g. vfio) should set DMA_OWNER_USER for >> a device before the userspace is allowed to access it, plus a fd pointer to >> mark the user identity so a single group cannot be operated by multiple >> users simultaneously. Vice versa, the owner type should be released after >> the user access permission is withdrawn. Best regards, baolu
next prev parent reply other threads:[~2021-11-16 1:57 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 [this message] 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 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=6a2e3d54-8c7f-0367-081b-5448d93f5ca5@linux.intel.com \ --to=baolu.lu@linux.intel.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=bhelgaas@google.com \ --cc=cohuck@redhat.com \ --cc=diana.craciun@oss.nxp.com \ --cc=gregkh@linuxfoundation.org \ --cc=helgaas@kernel.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.