All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Eric Auger <eric.auger@redhat.com>, Yi Liu <yi.l.liu@intel.com>
Subject: Re: [PATCH 04/10] vfio: Use a struct of function pointers instead of a many symbol_get()'s
Date: Fri, 15 Apr 2022 16:36:21 +0200	[thread overview]
Message-ID: <20220415143621.GA1958@lst.de> (raw)
In-Reply-To: <20220415121301.GH2120790@nvidia.com>

On Fri, Apr 15, 2022 at 09:13:01AM -0300, Jason Gunthorpe wrote:
> > So I got anoyed at this as well a while ago and I still think this
> > is the wrong way around.
> 
> What I plan to do in future is to have differnt ops returned depending
> on if the file is a struct vfio_group or a struct vfio_device, so it
> is not entirely pointless like this.

Uh, I think that is a rather ugly interface.  Why would kvm pass in
FDs to both into the same interface.

> 
> > I'd much rather EXPORT_SYMBOL_GPL kvm_register_device_ops and
> > just let kvm_vfio_ops live in a module than all the symbol_get
> > crazyness.  We'll need to be careful to deal with unload races
> > or just not allow unloading, though.
> 
> This is certainly more complicated - especially considering module
> unload - than a single symbol_get(). How do you see the benefit?

Because that is the sensible layering - kvm already has an abstract
interface for emulated devices.  So instead of doing symbol_get magic
of some kind we should leverage it.

But I can see how that is something you might not want to do for
this series.  So maybe stick to the individual symbol_gets for now
and I'll send a separate series to clean that up?  Especially as
I have a half-finished series for that from a while ago anyway.

> 
> Jason
---end quoted text---

  reply	other threads:[~2022-04-15 14:36 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 18:45 [PATCH 00/10] Remove vfio_group from the struct file facing VFIO API Jason Gunthorpe
2022-04-14 18:46 ` [PATCH 01/10] kvm/vfio: Move KVM_DEV_VFIO_GROUP_* ioctls into functions Jason Gunthorpe
2022-04-15  3:36   ` Tian, Kevin
2022-04-15  7:18   ` Christoph Hellwig
2022-04-14 18:46 ` [PATCH 02/10] kvm/vfio: Reduce the scope of PPC #ifdefs Jason Gunthorpe
2022-04-15  4:47   ` Christoph Hellwig
2022-04-15 12:13     ` Jason Gunthorpe
2022-04-15 12:35       ` Jason Gunthorpe
2022-04-15 14:36         ` Christoph Hellwig
2022-04-14 18:46 ` [PATCH 03/10] kvm/vfio: Store the struct file in the kvm_vfio_group Jason Gunthorpe
2022-04-15  3:44   ` Tian, Kevin
2022-04-15 22:24     ` Jason Gunthorpe
2022-04-15  7:20   ` Christoph Hellwig
2022-04-19 19:24     ` Jason Gunthorpe
2022-04-14 18:46 ` [PATCH 04/10] vfio: Use a struct of function pointers instead of a many symbol_get()'s Jason Gunthorpe
2022-04-15  3:57   ` Tian, Kevin
2022-04-15 21:54     ` Jason Gunthorpe
2022-04-16  0:00       ` Tian, Kevin
2022-04-16  1:33         ` Jason Gunthorpe
2022-04-18  3:56           ` Tian, Kevin
2022-04-19 12:16             ` Jason Gunthorpe
2022-04-15  4:45   ` Christoph Hellwig
2022-04-15 12:13     ` Jason Gunthorpe
2022-04-15 14:36       ` Christoph Hellwig [this message]
2022-04-15 15:31         ` Jason Gunthorpe
2022-04-14 18:46 ` [PATCH 05/10] vfio: Move vfio_external_user_iommu_id() to vfio_file_ops Jason Gunthorpe
2022-04-15  3:59   ` Tian, Kevin
2022-04-15  7:31   ` Christoph Hellwig
2022-04-15 12:25     ` Jason Gunthorpe
2022-04-15 14:37       ` Christoph Hellwig
2022-04-14 18:46 ` [PATCH 06/10] vfio: Remove vfio_external_group_match_file() Jason Gunthorpe
2022-04-15  4:02   ` Tian, Kevin
2022-04-15  7:32   ` Christoph Hellwig
2022-04-14 18:46 ` [PATCH 07/10] vfio: Move vfio_external_check_extension() to vfio_file_ops Jason Gunthorpe
2022-04-15  4:07   ` Tian, Kevin
2022-04-19 19:23     ` Jason Gunthorpe
2022-04-20  3:05       ` Tian, Kevin
2022-04-15  4:48   ` Christoph Hellwig
2022-04-14 18:46 ` [PATCH 08/10] vfio: Move vfio_group_set_kvm() into vfio_file_ops Jason Gunthorpe
2022-04-15  4:09   ` Tian, Kevin
2022-04-14 18:46 ` [PATCH 09/10] kvm/vfio: Remove vfio_group from kvm Jason Gunthorpe
2022-04-15  4:21   ` Tian, Kevin
2022-04-15 21:56     ` Jason Gunthorpe
2022-04-16  0:42       ` Tian, Kevin
2022-04-16  1:34         ` Jason Gunthorpe
2022-04-18  6:09           ` Tian, Kevin
2022-04-14 18:46 ` [PATCH 10/10] vfio/pci: Use the struct file as the handle not the vfio_group Jason Gunthorpe

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=20220415143621.GA1958@lst.de \
    --to=hch@lst.de \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=yi.l.liu@intel.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.