From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org> To: Alex Williamson <alex.williamson@redhat.com> Cc: kvm@vger.kernel.org, cohuck@redhat.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, Robin Murphy <robin.murphy@arm.com> Subject: Re: [PATCH v2 1/2] vfio/type1: Simplify bus_type determination Date: Fri, 24 Jun 2022 11:56:27 -0300 [thread overview] Message-ID: <20220624145627.GU4147@nvidia.com> (raw) In-Reply-To: <20220624082831.22de3d51.alex.williamson@redhat.com> On Fri, Jun 24, 2022 at 08:28:31AM -0600, Alex Williamson wrote: > > > That's essentially what I'm suggesting, the vfio_group is passed as an > > > opaque pointer which type1 can use for a > > > vfio_group_for_each_vfio_device() type call. Thanks, > > > > I don't want to add a whole vfio_group_for_each_vfio_device() > > machinery that isn't actually needed by anything.. This is all > > internal, we don't need to design more than exactly what is needed. > > > > At this point if we change the signature of the attach then we may as > > well just pass in the representative vfio_device, that is probably > > less LOC overall. > > That means that vfio core still needs to pick an arbitrary > representative device, which I find in fundamental conflict to the > nature of groups. Well, this is where iommu is going, I think Robin has explained this view well enough. Ideally we'd move VFIO away from trying to attach groups and attach when the device FD is opened, I view this as a micro step in that direction. > Type1 is the interface to the IOMMU API, if through the IOMMU API we > can make an assumption that all devices within the group are > equivalent for a given operation, that should be done in type1 code, > not in vfio core. iommu_group is part of the core code, if the representative device assumption stems from the iommu_group then the core code can safely make it. > A for-each interface is commonplace and not significantly more code > or design than already proposed. Except that someone else might get the idea to use it for something completely inappropriate. Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com> To: Alex Williamson <alex.williamson@redhat.com> Cc: Robin Murphy <robin.murphy@arm.com>, cohuck@redhat.com, iommu@lists.linux.dev, iommu@lists.linux-foundation.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] vfio/type1: Simplify bus_type determination Date: Fri, 24 Jun 2022 11:56:27 -0300 [thread overview] Message-ID: <20220624145627.GU4147@nvidia.com> (raw) In-Reply-To: <20220624082831.22de3d51.alex.williamson@redhat.com> On Fri, Jun 24, 2022 at 08:28:31AM -0600, Alex Williamson wrote: > > > That's essentially what I'm suggesting, the vfio_group is passed as an > > > opaque pointer which type1 can use for a > > > vfio_group_for_each_vfio_device() type call. Thanks, > > > > I don't want to add a whole vfio_group_for_each_vfio_device() > > machinery that isn't actually needed by anything.. This is all > > internal, we don't need to design more than exactly what is needed. > > > > At this point if we change the signature of the attach then we may as > > well just pass in the representative vfio_device, that is probably > > less LOC overall. > > That means that vfio core still needs to pick an arbitrary > representative device, which I find in fundamental conflict to the > nature of groups. Well, this is where iommu is going, I think Robin has explained this view well enough. Ideally we'd move VFIO away from trying to attach groups and attach when the device FD is opened, I view this as a micro step in that direction. > Type1 is the interface to the IOMMU API, if through the IOMMU API we > can make an assumption that all devices within the group are > equivalent for a given operation, that should be done in type1 code, > not in vfio core. iommu_group is part of the core code, if the representative device assumption stems from the iommu_group then the core code can safely make it. > A for-each interface is commonplace and not significantly more code > or design than already proposed. Except that someone else might get the idea to use it for something completely inappropriate. Jason
next prev parent reply other threads:[~2022-06-24 14:56 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-22 12:04 [PATCH v2 1/2] vfio/type1: Simplify bus_type determination Robin Murphy 2022-06-22 12:04 ` Robin Murphy 2022-06-22 12:04 ` [PATCH v2 2/2] vfio: Use device_iommu_capable() Robin Murphy 2022-06-22 12:04 ` Robin Murphy 2022-06-23 1:47 ` Baolu Lu 2022-06-23 1:47 ` Baolu Lu 2022-06-22 22:17 ` [PATCH v2 1/2] vfio/type1: Simplify bus_type determination Alex Williamson 2022-06-22 22:17 ` Alex Williamson 2022-06-23 8:46 ` Tian, Kevin 2022-06-23 8:46 ` Tian, Kevin 2022-06-23 20:35 ` Alex Williamson 2022-06-23 20:35 ` Alex Williamson 2022-06-23 12:23 ` Robin Murphy 2022-06-23 12:23 ` Robin Murphy 2022-06-23 20:50 ` Jason Gunthorpe 2022-06-23 20:50 ` Jason Gunthorpe via iommu 2022-06-23 23:00 ` Alex Williamson 2022-06-23 23:00 ` Alex Williamson 2022-06-24 1:50 ` Jason Gunthorpe 2022-06-24 1:50 ` Jason Gunthorpe via iommu 2022-06-24 14:11 ` Alex Williamson 2022-06-24 14:11 ` Alex Williamson 2022-06-24 14:18 ` Jason Gunthorpe 2022-06-24 14:18 ` Jason Gunthorpe via iommu 2022-06-24 14:28 ` Alex Williamson 2022-06-24 14:28 ` Alex Williamson 2022-06-24 14:56 ` Jason Gunthorpe via iommu [this message] 2022-06-24 14:56 ` Jason Gunthorpe 2022-06-24 15:12 ` Robin Murphy 2022-06-24 15:12 ` Robin Murphy 2022-06-24 16:04 ` Alex Williamson 2022-06-24 16:04 ` Alex Williamson 2022-06-23 1:46 ` Baolu Lu 2022-06-23 1:46 ` Baolu Lu 2022-06-23 4:32 ` kernel test robot 2022-06-23 4:32 ` kernel test robot 2022-06-24 1:52 ` Jason Gunthorpe 2022-06-24 1:52 ` 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=20220624145627.GU4147@nvidia.com \ --to=iommu@lists.linux-foundation.org \ --cc=alex.williamson@redhat.com \ --cc=cohuck@redhat.com \ --cc=iommu@lists.linux.dev \ --cc=jgg@nvidia.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --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.