kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Max Gurtovoy <mgurtovoy@nvidia.com>, <kvm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <liranl@nvidia.com>,
	<oren@nvidia.com>, <tzahio@nvidia.com>, <leonro@nvidia.com>,
	<yarong@nvidia.com>, <aviadye@nvidia.com>, <shahafs@nvidia.com>,
	<artemp@nvidia.com>, <kwankhede@nvidia.com>, <ACurrid@nvidia.com>,
	<gmataev@nvidia.com>, <cjia@nvidia.com>
Subject: Re: [PATCH RFC v1 0/3] Introduce vfio-pci-core subsystem
Date: Mon, 25 Jan 2021 17:20:35 +0100	[thread overview]
Message-ID: <20210125172035.3b61b91b.cohuck@redhat.com> (raw)
In-Reply-To: <20210122200421.GH4147@nvidia.com>

On Fri, 22 Jan 2021 16:04:21 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Fri, Jan 22, 2021 at 12:25:03PM -0700, Alex Williamson wrote:

> > > In this way, we'll use the HW vendor driver core to manage the lifecycle
> > > of these devices. This is reasonable since only the vendor driver knows
> > > exactly about the status on its internal state and the capabilities of
> > > its acceleratots, for example.  
> > 
> > But mdev provides that too, or the vendor could write their own vfio  
> 
> Not really, mdev has a completely different lifecycle model that is
> not very compatible with what is required here.
> 
> And writing a VFIO driver is basically what this does, just a large
> portion of the driver is reusing code from the normal vfio-pci cases.

I think you cut out an important part of Alex' comment, so let me
repost it here:

"But mdev provides that too, or the vendor could write their own vfio
bus driver for the device, this doesn't really justify or delve deep
enough to show examples beyond "TODO" remarks for a vendor driver
actually interacting with vfio-pci-core in an extensible way.  One of
the concerns of previous efforts was that it's trying to directly
expose vfio-pci's implementation as an API for vendor drivers, I don't
really see that anything has changed in that respect here."

I'm missing the bigger picture of how this api is supposed to work out,
a driver with a lot of TODOs does not help much to figure out whether
this split makes sense and is potentially useful for a number of use
cases, or whether mdev (even with its different lifecycle model) or a
different vfio bus driver might be a better fit for the more involved
cases. (For example, can s390 ISM fit here?)


  reply	other threads:[~2021-01-25 16:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 18:15 [PATCH RFC v1 0/3] Introduce vfio-pci-core subsystem Max Gurtovoy
2021-01-17 18:15 ` [PATCH 1/3] vfio-pci: rename vfio_pci.c to vfio_pci_core.c Max Gurtovoy
2021-01-17 18:15 ` [PATCH 2/3] vfio-pci: introduce vfio_pci_core subsystem driver Max Gurtovoy
2021-01-17 18:15 ` [PATCH 3/3] mlx5-vfio-pci: add new vfio_pci driver for mlx5 devices Max Gurtovoy
2021-01-18 13:38 ` [PATCH RFC v1 0/3] Introduce vfio-pci-core subsystem Cornelia Huck
2021-01-18 15:10   ` Jason Gunthorpe
2021-01-18 16:00     ` Cornelia Huck
2021-01-18 18:16       ` Jason Gunthorpe
2021-01-19 18:56         ` Cornelia Huck
2021-01-19 19:42           ` Jason Gunthorpe
2021-01-22 19:25 ` Alex Williamson
2021-01-22 20:04   ` Jason Gunthorpe
2021-01-25 16:20     ` Cornelia Huck [this message]
2021-01-25 18:04       ` Jason Gunthorpe
2021-01-25 23:31         ` Alex Williamson
2021-01-26  0:45           ` Jason Gunthorpe
2021-01-26  3:34             ` Alex Williamson
2021-01-26 13:27               ` Max Gurtovoy
2021-01-28 16:29                 ` Cornelia Huck
2021-01-28 21:02                   ` Alex Williamson
2021-01-31 18:46                     ` Max Gurtovoy
2021-02-01  4:32                       ` Alex Williamson
2021-02-01  9:40                         ` Max Gurtovoy
2021-02-01 17:29                           ` Alex Williamson
2021-02-01 17:17                         ` Jason Gunthorpe
2021-01-31 18:09                   ` Max Gurtovoy
2021-01-26 17:23               ` 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=20210125172035.3b61b91b.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=ACurrid@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=artemp@nvidia.com \
    --cc=aviadye@nvidia.com \
    --cc=cjia@nvidia.com \
    --cc=gmataev@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=leonro@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liranl@nvidia.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=oren@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=tzahio@nvidia.com \
    --cc=yarong@nvidia.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).