public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>,
	"Kernel Mailing List, Linux" <linux-kernel@vger.kernel.org>,
	kvm <kvm@vger.kernel.org>, Steffen Eiden <seiden@linux.ibm.com>,
	Alex Williamson <alex.williamson@nvidia.com>
Subject: Re: [PATCH 1/3] VFIO: take reference to the KVM module
Date: Fri, 10 Apr 2026 15:18:46 -0300	[thread overview]
Message-ID: <20260410181846.GH2551565@ziepe.ca> (raw)
In-Reply-To: <CABgObfZQ8kcdfiaUyGi6AcZErJztEmcdTcLwo946qtXfUwDM4g@mail.gmail.com>

On Fri, Apr 10, 2026 at 10:16:09AM +0200, Paolo Bonzini wrote:
> Il gio 9 apr 2026, 20:59 Sean Christopherson <seanjc@google.com> ha scritto:
> >
> > On Tue, Apr 07, 2026, Paolo Bonzini wrote:
> > > VFIO is implicitly taking a reference to the KVM module between
> > > vfio_device_get_kvm_safe and vfio_device_put_kvm, thanks to
> > > symbol_get and symbol_put.
> > >
> > > In preparation for removing symbol_get and symbol_put themselves
> > > from VFIO, actually store a pointer to the KVM module and use
> > > module_get()/module_put() to keep KVM alive.
> >
> > NAK?  :-)
> >
> > I really don't think we should do this.  We're reinventing the wheel, and probably
> > doing so poorly.  As Jason suggested, the proper way to handle this is to pass
> > a "struct file" so that e.g. fops_get() pins kvm.ko for us.
> 
> We could get rid of the reference count completely (get_file() as a
> replacement for kvm_get_kvm(), get_file_active() as a replacement for
> kvm_get_kvm_safe()). struct kvm would need to add a back pointer from
> struct kvm to struct file, therefore adding and removing a reference
> count would have some additional pointer chasing. KVM has too many
> kinds of files to seriously consider passing around struct file* in
> virt/kvm/ and arch/*/kvm/, and you'd also have pointer chasing to get
> filp->private_data so it wouldn't win much.
> 
> Passing both struct kvm and struct file, instead, would be worse
> conceptually than this patch (because VFIO doesn't really care about
> the fops as opposed to the module) and uglier:
> - you can introduce a back pointer to struct kvm
> - you can change all struct kvm_device_ops implementations to receive
> a struct file*
> 
> While I can look at using the file reference for struct kvm, I'm not
> sure it's a win overall.

I would be much happier if vfio could just hang onto the file and kvm
could use file->private to get its stuff. It is so much cleaner and
simpler and keeps all the kvm stuff away from VFIO. We are trying to
do the same design for iommufd's kvm handle too, so I would prefer the
symmetry.

It seems to hinge on if virt/kvm/vfio.c can call vfio_file_set_kvm()
with a file * instead of a kvm *? A back pointer seems like an easy
way to do that?

Jason

  parent reply	other threads:[~2026-04-10 18:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 18:01 [PATCH 0/3] KVM, vfio: remove exported KVM symbols Paolo Bonzini
2026-04-07 18:01 ` [PATCH 1/3] VFIO: take reference to the KVM module Paolo Bonzini
2026-04-09 15:00   ` Steffen Eiden
2026-04-09 18:59   ` Sean Christopherson
2026-04-10  8:16     ` Paolo Bonzini
2026-04-10 14:13       ` Sean Christopherson
2026-04-10 14:34         ` Paolo Bonzini
2026-04-10 15:45           ` Sean Christopherson
2026-04-10 22:20         ` Dan Williams
2026-04-10 18:18       ` Jason Gunthorpe [this message]
2026-04-10 18:12   ` Jason Gunthorpe
2026-04-07 18:01 ` [PATCH 2/3] KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio Paolo Bonzini
2026-04-09 15:01   ` Steffen Eiden
2026-04-07 18:01 ` [PATCH 3/3] KVM, vfio: remove symbol_get(kvm_put_kvm) " Paolo Bonzini
2026-04-09 15:02   ` Steffen Eiden
2026-04-07 20:16 ` [PATCH 0/3] KVM, vfio: remove exported KVM symbols Alex Williamson
2026-04-09 15:06 ` Steffen Eiden

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=20260410181846.GH2551565@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=alex.williamson@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=seiden@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox