RE: [virtio-comment] Re: [PATCH v18] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, June 22, 2023 1:28 PM

> > > If VF is assigned then we can't really control what does guest enable.
> > >
> > All parameters set over the CVQ needs to be accessible to the migration entity.
> > Including RSS and including this bit.
> > Either by trapping the CVQ or by having AQ command to query member dev
> capabilities.
> 
> Yes, parameters set needs to be trapped, so they can be replayed. 
Only for vdpa type of solution.

For passthrough device no need to trap any parameters or capability. 

> This is a
> capability though. After guest has driven the CVQ for a while submitting a
> command to it so we get capability - I don't see how that works.
> 
Group owner device gets to query the capabilities (and provision) using admin command.
(already part of transport vq proposal).

> > > > > But querying over cvq while VF is assigned clearly *doesn't* work.
> > > > >
> > > > That is not the idea at all.
> > > > Querying VF capabilities is the role of the admin command for
> > > > which we built
> > > it.
> > >
> > > This GET is exactly that though.
> > >
> > Not exactly.
> > This GET command is needed for the member driver to know what is
> supported for the device it got.
> 
> yes. but how will hypervisor get the capability?
>
By issuing admin command on the group owner device.

> > > > > So what is the solution proposed for this?
> > > > >
> > > > 1. Query member device capabilities via admin command
> > >
> > > But that's not 1.3 material.
> > >
> > > > > Yes the current migration is broken in many ways but that's what
> > > > > we have. Let's build something better sure but that is not 1.3 material.
> > > >
> > > > True, it is not 1.3 material, hence the proposal was to have the GET
> command.
> > > > Once/if we reach agreement that no new fields to be added to
> > > > config space
> > > starting 1.4 and should be queried using non intercepted cfgvq, it
> > > makes sense to let this go in cfg space.
> > > > Else GET command seems the elegant and right approach.
> > >
> > > I expect no such agreement at all. Instead, I expect that we'll have
> > > an alternative way to access config space. guest virtio core then
> > > needs to learn both ways, and devices can support one or both.
> > >
> > Yeah, we disagree.
> > Because alternative way that you propose is not predictable way to build the
> device efficiently.
> > It always needs to account for old driver to support.
> > This is clearly sub-optimal as the capabilities grow.
> 
> So just quickly add the new capability in the spec and then the number of linux
> releases that will have the new feature but not config command or whatever
> that is will be too small for vendors to care.
> 
I didn't follow this suggestion.

> >
> > > A good implementation of virtio_cread can abstract that easily so we
> > > don't need to change drivers.
> >
> > There is no backward compat issue for the GET command being new.
> 
> It's just a shortcut replacing what we really want.  As long as a shortcut is
> available people will keep using exactly that.  So I fully expect more proposals
> for such GET commands on the pretext that one is there so why not another
> one. Adding more tech debt for whoever finally gets around to building a config
> space access gateway.
>
Not really. as suggested, the first addition of new field to the config space in 1.4-time frame, should add the cfgvq, and not follow the previous example.
Because this is being thought through now, it is not at all hard for any new things to follow the guideline.