Virtualization - Sep 2023 - [PATCH vfio 10/11] vfio/virtio: Expose admin commands over virtio device

On Wed, Sep 27, 2023 at 08:16:00PM -0300, Jason Gunthorpe
wrote:
> On Wed, Sep 27, 2023 at 05:30:04PM -0400, Michael S. Tsirkin wrote:
> > 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.
> 
> If you can't reliably issue commmands from the VF at all it doesn't
> really matter where you put the code. Once that is established up then
> an admin command execution interface is a nice cut point for
> modularity.
> 
> The locking in mlx5 to make this safe is not too complex, if Feng
> missed some items for virtio then he can work to fix it up.
Above two paragraphs don't make sense to me at all. VF issues
no commands and there's no locking.
> > > 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.
> 
> I have a doubt, you both said vdpa already does live migration, so
> what will it even do with a live migration interface to a PCI
> function?
This is not the thread to explain how vdpa live migration works now and
why it needs new interfaces, sorry. Suffice is to say right now on virtio
tc Parav from nvidia is arguing for vdpa to use admin commands for
migration.
> It already has to use full mediation to operate a physical virtio
> function, so it seems like it shouldn't need the migration interface?
> 
> Regardless, it is better kernel development hygiene to put the code
> where it is used and wait for a second user to consolidate it than to
> guess.
> 
> Jason
Sorry no time right now to argue philosophy. I gave some hints on how to
make the virtio changes behave in a way that I'm ok with maintaining.
Hope they help.

-- 
MST