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. > > 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. Parav, are there other things? Jason
