All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.