From: "Tian, Kevin" <kevin.tian@intel.com> To: Alex Williamson <alex.williamson@redhat.com>, Jason Gunthorpe <jgg@nvidia.com> Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Jason Wang <jasowang@redhat.com>, Kirti Wankhede <kwankhede@nvidia.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, "Jiang, Dave" <dave.jiang@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>, Jonathan Corbet <corbet@lwn.net>, "parav@mellanox.com" <parav@mellanox.com>, "Enrico Weigelt, metux IT consult" <lkml@metux.net>, David Gibson <david@gibson.dropbear.id.au>, Robin Murphy <robin.murphy@arm.com>, LKML <linux-kernel@vger.kernel.org>, Shenming Lu <lushenming@huawei.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Paolo Bonzini <pbonzini@redhat.com>, David Woodhouse <dwmw2@infradead.org> Subject: RE: Plan for /dev/ioasid RFC v2 Date: Tue, 15 Jun 2021 02:31:39 +0000 [thread overview] Message-ID: <MWHPR11MB1886239C82D6B66A732830B88C309@MWHPR11MB1886.namprd11.prod.outlook.com> (raw) In-Reply-To: <20210614102814.43ada8df.alex.williamson@redhat.com> > From: Alex Williamson <alex.williamson@redhat.com> > Sent: Tuesday, June 15, 2021 12:28 AM > [...] > > IOASID. Today the group fd requires an IOASID before it hands out a > > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it > > has a blocked DMA IOASID and is successefully joined to an iommu_fd. > > Which is the root of my concern. Who owns ioctls to the device fd? > It's my understanding this is a vfio provided file descriptor and it's > therefore vfio's responsibility. A device-level IOASID interface > therefore requires that vfio manage the group aspect of device access. > AFAICT, that means that device access can therefore only begin when all > devices for a given group are attached to the IOASID and must halt for > all devices in the group if any device is ever detached from an IOASID, > even temporarily. That suggests a lot more oversight of the IOASIDs by > vfio than I'd prefer. > This is possibly the point that is worthy of more clarification and alignment, as it sounds like the root of controversy here. I feel the goal of vfio group management is more about ownership, i.e. all devices within a group must be assigned to a single user. Following the three rules defined by Jason, what we really care is whether a group of devices can be isolated from the rest of the world, i.e. no access to memory/device outside of its security context and no access to its security context from devices outside of this group. This can be achieved as long as every device in the group is either in block-DMA state when it's not attached to any security context or attached to an IOASID context in IOMMU fd. As long as group-level isolation is satisfied, how devices within a group are further managed is decided by the user (unattached, all attached to same IOASID, attached to different IOASIDs) as long as the user understands the implication of lacking of isolation within the group. This is what a device-centric model comes to play. Misconfiguration just hurts the user itself. If this rationale can be agreed, then I didn't see the point of having VFIO to mandate all devices in the group must be attached/detached in lockstep. Thanks Kevin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: "Tian, Kevin" <kevin.tian@intel.com> To: Alex Williamson <alex.williamson@redhat.com>, Jason Gunthorpe <jgg@nvidia.com> Cc: Joerg Roedel <joro@8bytes.org>, Jean-Philippe Brucker <jean-philippe@linaro.org>, David Gibson <david@gibson.dropbear.id.au>, "Jason Wang" <jasowang@redhat.com>, "parav@mellanox.com" <parav@mellanox.com>, "Enrico Weigelt, metux IT consult" <lkml@metux.net>, Paolo Bonzini <pbonzini@redhat.com>, Shenming Lu <lushenming@huawei.com>, Eric Auger <eric.auger@redhat.com>, Jonathan Corbet <corbet@lwn.net>, "Raj, Ashok" <ashok.raj@intel.com>, "Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>, "Jiang, Dave" <dave.jiang@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>, Kirti Wankhede <kwankhede@nvidia.com>, "Robin Murphy" <robin.murphy@arm.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "David Woodhouse" <dwmw2@infradead.org>, LKML <linux-kernel@vger.kernel.org>, "Lu Baolu" <baolu.lu@linux.intel.com> Subject: RE: Plan for /dev/ioasid RFC v2 Date: Tue, 15 Jun 2021 02:31:39 +0000 [thread overview] Message-ID: <MWHPR11MB1886239C82D6B66A732830B88C309@MWHPR11MB1886.namprd11.prod.outlook.com> (raw) In-Reply-To: <20210614102814.43ada8df.alex.williamson@redhat.com> > From: Alex Williamson <alex.williamson@redhat.com> > Sent: Tuesday, June 15, 2021 12:28 AM > [...] > > IOASID. Today the group fd requires an IOASID before it hands out a > > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it > > has a blocked DMA IOASID and is successefully joined to an iommu_fd. > > Which is the root of my concern. Who owns ioctls to the device fd? > It's my understanding this is a vfio provided file descriptor and it's > therefore vfio's responsibility. A device-level IOASID interface > therefore requires that vfio manage the group aspect of device access. > AFAICT, that means that device access can therefore only begin when all > devices for a given group are attached to the IOASID and must halt for > all devices in the group if any device is ever detached from an IOASID, > even temporarily. That suggests a lot more oversight of the IOASIDs by > vfio than I'd prefer. > This is possibly the point that is worthy of more clarification and alignment, as it sounds like the root of controversy here. I feel the goal of vfio group management is more about ownership, i.e. all devices within a group must be assigned to a single user. Following the three rules defined by Jason, what we really care is whether a group of devices can be isolated from the rest of the world, i.e. no access to memory/device outside of its security context and no access to its security context from devices outside of this group. This can be achieved as long as every device in the group is either in block-DMA state when it's not attached to any security context or attached to an IOASID context in IOMMU fd. As long as group-level isolation is satisfied, how devices within a group are further managed is decided by the user (unattached, all attached to same IOASID, attached to different IOASIDs) as long as the user understands the implication of lacking of isolation within the group. This is what a device-centric model comes to play. Misconfiguration just hurts the user itself. If this rationale can be agreed, then I didn't see the point of having VFIO to mandate all devices in the group must be attached/detached in lockstep. Thanks Kevin
next prev parent reply other threads:[~2021-06-15 2:31 UTC|newest] Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-07 2:58 Plan for /dev/ioasid RFC v2 Tian, Kevin 2021-06-07 2:58 ` Tian, Kevin 2021-06-09 8:14 ` Eric Auger 2021-06-09 8:14 ` Eric Auger 2021-06-09 9:37 ` Tian, Kevin 2021-06-09 9:37 ` Tian, Kevin 2021-06-09 10:14 ` Eric Auger 2021-06-09 10:14 ` Eric Auger 2021-06-09 9:01 ` Leon Romanovsky 2021-06-09 9:01 ` Leon Romanovsky 2021-06-09 9:43 ` Tian, Kevin 2021-06-09 9:43 ` Tian, Kevin 2021-06-09 12:24 ` Joerg Roedel 2021-06-09 12:24 ` Joerg Roedel 2021-06-09 12:39 ` Jason Gunthorpe 2021-06-09 12:39 ` Jason Gunthorpe 2021-06-09 13:32 ` Joerg Roedel 2021-06-09 13:32 ` Joerg Roedel 2021-06-09 15:00 ` Jason Gunthorpe 2021-06-09 15:00 ` Jason Gunthorpe 2021-06-09 15:51 ` Joerg Roedel 2021-06-09 15:51 ` Joerg Roedel 2021-06-09 16:15 ` Alex Williamson 2021-06-09 16:15 ` Alex Williamson 2021-06-09 16:27 ` Alex Williamson 2021-06-09 16:27 ` Alex Williamson 2021-06-09 18:49 ` Jason Gunthorpe 2021-06-09 18:49 ` Jason Gunthorpe 2021-06-10 15:38 ` Alex Williamson 2021-06-10 15:38 ` Alex Williamson 2021-06-11 0:58 ` Tian, Kevin 2021-06-11 0:58 ` Tian, Kevin 2021-06-11 21:38 ` Alex Williamson 2021-06-11 21:38 ` Alex Williamson 2021-06-14 3:09 ` Tian, Kevin 2021-06-14 3:09 ` Tian, Kevin 2021-06-14 3:22 ` Alex Williamson 2021-06-14 3:22 ` Alex Williamson 2021-06-15 1:05 ` Tian, Kevin 2021-06-15 1:05 ` Tian, Kevin 2021-06-14 13:38 ` Jason Gunthorpe 2021-06-14 13:38 ` Jason Gunthorpe 2021-06-15 1:21 ` Tian, Kevin 2021-06-15 1:21 ` Tian, Kevin 2021-06-15 16:56 ` Alex Williamson 2021-06-15 16:56 ` Alex Williamson 2021-06-16 6:53 ` Tian, Kevin 2021-06-16 6:53 ` Tian, Kevin 2021-06-24 4:50 ` David Gibson 2021-06-24 4:50 ` David Gibson 2021-06-11 16:45 ` Jason Gunthorpe 2021-06-11 16:45 ` Jason Gunthorpe 2021-06-11 19:38 ` Alex Williamson 2021-06-11 19:38 ` Alex Williamson 2021-06-12 1:28 ` Jason Gunthorpe 2021-06-12 1:28 ` Jason Gunthorpe 2021-06-12 16:57 ` Alex Williamson 2021-06-12 16:57 ` Alex Williamson 2021-06-14 14:07 ` Jason Gunthorpe 2021-06-14 14:07 ` Jason Gunthorpe 2021-06-14 16:28 ` Alex Williamson 2021-06-14 16:28 ` Alex Williamson 2021-06-14 19:40 ` Jason Gunthorpe 2021-06-14 19:40 ` Jason Gunthorpe 2021-06-15 2:31 ` Tian, Kevin [this message] 2021-06-15 2:31 ` Tian, Kevin 2021-06-15 16:12 ` Alex Williamson 2021-06-15 16:12 ` Alex Williamson 2021-06-16 6:43 ` Tian, Kevin 2021-06-16 6:43 ` Tian, Kevin 2021-06-16 19:39 ` Alex Williamson 2021-06-16 19:39 ` Alex Williamson 2021-06-17 3:39 ` Liu Yi L 2021-06-17 3:39 ` Liu Yi L 2021-06-17 7:31 ` Tian, Kevin 2021-06-17 7:31 ` Tian, Kevin 2021-06-17 21:14 ` Alex Williamson 2021-06-17 21:14 ` Alex Williamson 2021-06-18 0:19 ` Jason Gunthorpe 2021-06-18 0:19 ` Jason Gunthorpe 2021-06-18 16:57 ` Tian, Kevin 2021-06-18 16:57 ` Tian, Kevin 2021-06-18 18:23 ` Jason Gunthorpe 2021-06-18 18:23 ` Jason Gunthorpe 2021-06-25 10:27 ` Tian, Kevin 2021-06-25 10:27 ` Tian, Kevin 2021-06-25 14:36 ` Jason Gunthorpe 2021-06-25 14:36 ` Jason Gunthorpe 2021-06-28 1:09 ` Tian, Kevin 2021-06-28 1:09 ` Tian, Kevin 2021-06-28 22:31 ` Alex Williamson 2021-06-28 22:31 ` Alex Williamson 2021-06-28 22:48 ` Jason Gunthorpe 2021-06-28 22:48 ` Jason Gunthorpe 2021-06-28 23:09 ` Alex Williamson 2021-06-28 23:09 ` Alex Williamson 2021-06-28 23:13 ` Jason Gunthorpe 2021-06-28 23:13 ` Jason Gunthorpe 2021-06-29 0:26 ` Tian, Kevin 2021-06-29 0:26 ` Tian, Kevin 2021-06-29 0:28 ` Tian, Kevin 2021-06-29 0:28 ` Tian, Kevin 2021-06-29 0:43 ` Tian, Kevin 2021-06-29 0:43 ` Tian, Kevin 2021-06-28 2:03 ` Tian, Kevin 2021-06-28 2:03 ` Tian, Kevin 2021-06-28 14:41 ` Jason Gunthorpe 2021-06-28 14:41 ` Jason Gunthorpe 2021-06-28 6:45 ` Tian, Kevin 2021-06-28 6:45 ` Tian, Kevin 2021-06-28 16:26 ` Jason Gunthorpe 2021-06-28 16:26 ` Jason Gunthorpe 2021-06-24 4:26 ` David Gibson 2021-06-24 4:26 ` David Gibson 2021-06-24 5:59 ` Tian, Kevin 2021-06-24 5:59 ` Tian, Kevin 2021-06-24 12:22 ` Lu Baolu 2021-06-24 12:22 ` Lu Baolu 2021-06-24 4:23 ` David Gibson 2021-06-24 4:23 ` David Gibson 2021-06-18 0:52 ` Jason Gunthorpe 2021-06-18 0:52 ` Jason Gunthorpe 2021-06-18 13:47 ` Joerg Roedel 2021-06-18 13:47 ` Joerg Roedel 2021-06-18 15:15 ` Jason Gunthorpe 2021-06-18 15:15 ` Jason Gunthorpe 2021-06-18 15:37 ` Raj, Ashok 2021-06-18 15:37 ` Raj, Ashok 2021-06-18 15:51 ` Alex Williamson 2021-06-18 15:51 ` Alex Williamson 2021-06-24 4:29 ` David Gibson 2021-06-24 4:29 ` David Gibson 2021-06-24 11:56 ` Jason Gunthorpe 2021-06-24 11:56 ` Jason Gunthorpe 2021-06-18 0:10 ` Jason Gunthorpe 2021-06-18 0:10 ` Jason Gunthorpe 2021-06-17 5:29 ` David Gibson 2021-06-17 5:29 ` David Gibson 2021-06-17 5:02 ` David Gibson 2021-06-17 5:02 ` David Gibson 2021-06-17 23:04 ` Jason Gunthorpe 2021-06-17 23:04 ` Jason Gunthorpe 2021-06-24 4:37 ` David Gibson 2021-06-24 4:37 ` David Gibson 2021-06-24 11:57 ` Jason Gunthorpe 2021-06-24 11:57 ` Jason Gunthorpe 2021-06-10 5:50 ` Lu Baolu 2021-06-10 5:50 ` Lu Baolu 2021-06-17 5:22 ` David Gibson 2021-06-17 5:22 ` David Gibson 2021-06-18 5:21 ` Lu Baolu 2021-06-18 5:21 ` Lu Baolu 2021-06-24 4:03 ` David Gibson 2021-06-24 4:03 ` David Gibson 2021-06-24 13:42 ` Lu Baolu 2021-06-24 13:42 ` Lu Baolu 2021-06-17 4:45 ` David Gibson 2021-06-17 4:45 ` David Gibson 2021-06-17 23:10 ` Jason Gunthorpe 2021-06-17 23:10 ` Jason Gunthorpe 2021-06-24 4:07 ` David Gibson 2021-06-24 4:07 ` David Gibson
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=MWHPR11MB1886239C82D6B66A732830B88C309@MWHPR11MB1886.namprd11.prod.outlook.com \ --to=kevin.tian@intel.com \ --cc=alex.williamson@redhat.com \ --cc=ashok.raj@intel.com \ --cc=corbet@lwn.net \ --cc=dave.jiang@intel.com \ --cc=david@gibson.dropbear.id.au \ --cc=dwmw2@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=jasowang@redhat.com \ --cc=jean-philippe@linaro.org \ --cc=jgg@nvidia.com \ --cc=kvm@vger.kernel.org \ --cc=kwankhede@nvidia.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lkml@metux.net \ --cc=lushenming@huawei.com \ --cc=parav@mellanox.com \ --cc=pbonzini@redhat.com \ --cc=robin.murphy@arm.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: 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.