From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "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>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH 1/3] VFIO: take reference to the KVM module
Date: Mon, 13 Apr 2026 14:21:33 -0700 [thread overview]
Message-ID: <ad1eXa_PirbQKqYJ@google.com> (raw)
In-Reply-To: <279763ec-438a-46a2-b2fd-e5b445ab0160@redhat.com>
On Mon, Apr 13, 2026, Paolo Bonzini wrote:
> On 4/10/26 17:45, Sean Christopherson wrote:
> > On Fri, Apr 10, 2026, Paolo Bonzini wrote:
> > > On Fri, Apr 10, 2026 at 4:13 PM Sean Christopherson <seanjc@google.com> wrote:
> > > >
> > > > +Dan
> > > > > 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,
> > > >
> > > > I wasn't thinking of dropping kvm_get_kvm() entirely, rather just not exporting
> > > > it. Forcing internal KVM usage to grab a reference to the file doesn't add a
> > > > whole lot value.
> > >
> > > It adds not doing things in two different ways. The kvm_file is not
> > > always available (and if we need to add it, it should be added in
> > > struct kvm not struct kvm_device).
> >
> > My thought was to deliberately avoid putting it in "kvm", because as you're
> > effectively pointing out, the file really shouldn't be passed around within KVM.
> >
> > Aha! What if we bury it in kvm_vfio? As an acknowledgement that passing around
> > a kvm_file is only intended for cases where an external, non-KVM entity needs to
> > to propagate the VM reference.
>
> That would indeed be best but it doesn't compile as there's no file argument
> to device_ops.create. And adding it to device_ops is ugly as well.
FWIW, extending device_ops.create() doesn't seem all that ugly to me. It's not
beautiful, but I think I'd vote for that over a kvm->file backpointer. I'm a-ok
with either though.
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9faf70ccae7a..4e4e6b5c3b9c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -4811,7 +4811,7 @@ void kvm_unregister_device_ops(u32 type)
kvm_device_ops_table[type] = NULL;
}
-static int kvm_ioctl_create_device(struct kvm *kvm,
+static int kvm_ioctl_create_device(struct kvm *kvm, struct file *kvm_file,
struct kvm_create_device *cd)
{
const struct kvm_device_ops *ops;
@@ -4839,7 +4839,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
dev->kvm = kvm;
mutex_lock(&kvm->lock);
- ret = ops->create(dev, type);
+ ret = ops->create(dev, kvm_file, type);
if (ret < 0) {
mutex_unlock(&kvm->lock);
kfree(dev);
@@ -5354,7 +5354,7 @@ static long kvm_vm_ioctl(struct file *filp,
if (copy_from_user(&cd, argp, sizeof(cd)))
goto out;
- r = kvm_ioctl_create_device(kvm, &cd);
+ r = kvm_ioctl_create_device(kvm, filp, &cd);
if (r)
goto out;
next prev parent reply other threads:[~2026-04-13 21:21 UTC|newest]
Thread overview: 22+ 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-13 11:32 ` Paolo Bonzini
2026-04-13 21:21 ` Sean Christopherson [this message]
2026-04-10 22:20 ` Dan Williams
2026-04-16 0:31 ` Sean Christopherson
2026-04-16 7:30 ` Xu Yilun
2026-04-10 18:18 ` Jason Gunthorpe
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-11 12:26 ` kernel test robot
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=ad1eXa_PirbQKqYJ@google.com \
--to=seanjc@google.com \
--cc=alex.williamson@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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 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.