On Wed, Sep 27, 2023 at 10:18:17AM -0300, Jason Gunthorpe wrote: > On Tue, Sep 26, 2023 at 07:41:44AM -0400, Michael S. Tsirkin wrote: > > > > By the way, this follows what was done already between vfio/mlx5 to > > > mlx5_core modules where mlx5_core exposes generic APIs to execute a command > > > and to get the a PF from a given mlx5 VF. > > > > This is up to mlx5 maintainers. In particular they only need to worry > > that their patches work with specific hardware which they likely have. > > virtio has to work with multiple vendors - hardware and software - > > and exposing a low level API that I can't test on my laptop > > is not at all my ideal. > > mlx5 has a reasonable API from the lower level that allows the vfio > driver to safely issue commands. The API provides all the safety and > locking you have been questioning here. > > Then the vfio driver can form the commands directly and in the way it > needs. This avoids spewing code into the core modules that is only > used by vfio - which has been a key design consideration for our > driver layering. > > I suggest following the same design here as it has been well proven. > Provide a solid API to operate the admin queue and let VFIO use > it. One of the main purposes of the admin queue is to deliver commands > on behalf of the VF driver, so this is a logical and reasonable place > to put an API. Not the way virtio is designed now. I guess mlx5 is designed in a way that makes it safe. > > > This way, we can enable further commands to be added/extended > > > easily/cleanly. > > > > Something for vfio maintainer to consider in case it was > > assumed that it's just this one weird thing > > but otherwise it's all generic vfio. It's not going to stop there, > > will it? The duplication of functionality with vdpa will continue :( > > VFIO live migration is expected to come as well once OASIS completes > its work. Exactly. Is there doubt vdpa will want to support live migration? Put this code in a library please. > Parav, are there other things? > > Jason
