Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 25 Jan 2021 17:20:35 +0100
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
Message-ID: <20210125172035.3b61b91b.cohuck@redhat.com>
In-Reply-To: <20210122200421.GH4147@nvidia.com>
References: <20210117181534.65724-1-mgurtovoy@nvidia.com>
        <20210122122503.4e492b96@omen.home.shazbot.org>
        <20210122200421.GH4147@nvidia.com>
Organization: Red Hat GmbH
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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?)