virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
Cc: "Kim, Dongwon" <dongwon.kim@intel.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [RFC 3/3] vfio: Share the KVM instance with Vdmabuf
Date: Tue, 19 Jan 2021 17:50:57 -0700	[thread overview]
Message-ID: <20210119175057.5768b26b@x1.home.shazbot.org> (raw)
In-Reply-To: <b4a93e926d424ff199ab91ff88399087@intel.com>

On Wed, 20 Jan 2021 00:14:49 +0000
"Kasireddy, Vivek" <vivek.kasireddy@intel.com> wrote:

> Hi Alex,
> 
> > -----Original Message-----
> > From: Alex Williamson <alex.williamson@redhat.com>
> > Sent: Tuesday, January 19, 2021 7:40 AM
> > To: Kasireddy, Vivek <vivek.kasireddy@intel.com>
> > Cc: virtualization@lists.linux-foundation.org; Kim, Dongwon <dongwon.kim@intel.com>
> > Subject: Re: [RFC 3/3] vfio: Share the KVM instance with Vdmabuf
> > 
> > On Tue, 19 Jan 2021 00:28:12 -0800
> > Vivek Kasireddy <vivek.kasireddy@intel.com> wrote:
> >   
> > > Getting a copy of the KVM instance is necessary for mapping Guest
> > > pages in the Host.
> > >
> > > TODO: Instead of invoking the symbol directly, there needs to be a
> > > better way of getting a copy of the KVM instance probably by using
> > > other notifiers. However, currently, KVM shares its instance only
> > > with VFIO and therefore we are compelled to bind the passthrough'd
> > > device to vfio-pci.  
> > 
> > Yeah, this is a bad solution, sorry, vfio is not going to gratuitously
> > call out to vhost to share a kvm pointer.  I'd prefer to get rid of
> > vfio having any knowledge or visibility of the kvm pointer.  Thanks,  
> 
> [Kasireddy, Vivek] I agree that this is definitely not ideal as I recognize it
> in the TODO. However, it looks like VFIO also gets a copy of the KVM 
> pointer in a similar manner:
> 
> virt/kvm/vfio.c
> 
> static void kvm_vfio_group_set_kvm(struct vfio_group *group, struct kvm *kvm)
> {
>         void (*fn)(struct vfio_group *, struct kvm *);
> 
>         fn = symbol_get(vfio_group_set_kvm);
>         if (!fn)
>                 return;
> 
>         fn(group, kvm);
> 
>         symbol_put(vfio_group_set_kvm);
> }

You're equating the mechanism with the architecture.  We use symbols
here to avoid module dependencies between kvm and vfio, but this is
just propagating data that userspace is specifically registering
between kvm and vfio.  vhost doesn't get to piggyback on that channel.

> With this patch, I am not suggesting that this is a precedent that should be followed 
> but it appears there doesn't seem to be an alternative way of getting a copy of the KVM 
> pointer that is clean and elegant -- unless I have not looked hard enough. I guess we
> could create a notifier chain with callbacks for VFIO and Vhost that KVM would call 
> but this would mean modifying KVM.
> 
> Also, if I understand correctly, if VFIO does not want to share the KVM pointer with
> VFIO groups, then I think it would break stuff like mdev which counts on it. 

Only kvmgt requires the kvm pointer and the use case there is pretty
questionable, I wonder if it actually still exists now that we have the
DMA r/w interface through vfio.  Thanks,

Alex

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-01-20  0:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19  8:28 [RFC 0/3] Introduce Vdmabuf driver Vivek Kasireddy
2021-01-19  8:28 ` [RFC 1/3] virtio: " Vivek Kasireddy
2021-01-19  8:28 ` [RFC 2/3] vhost: Add Vdmabuf backend Vivek Kasireddy
2021-01-19  8:28 ` [RFC 3/3] vfio: Share the KVM instance with Vdmabuf Vivek Kasireddy
2021-01-19 15:39   ` Alex Williamson
2021-01-20  0:14     ` Kasireddy, Vivek
2021-01-20  0:50       ` Alex Williamson [this message]
2021-01-20  3:05         ` Tian, Kevin
2021-01-20  3:36           ` Alex Williamson
2021-01-21  3:15             ` Kasireddy, Vivek

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=20210119175057.5768b26b@x1.home.shazbot.org \
    --to=alex.williamson@redhat.com \
    --cc=dongwon.kim@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=vivek.kasireddy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).