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:11 PM

> > Provisioning driver usually do not attach to the member device directly.
> > This requires device reset, followed by reaching _DRIVER stage, querying
> features etc and config area.
> > And unbinding it and second reset by member driver. Ugh.
> > Provisioning driver also needs to get the state or capabilities even when
> member driver is already attached.
> > So config space is not much a gain either.
> 
> Actually it's RO so you *can* read it without any issues:

It is RO but not same across all devices.

> - block guest access to status
> - check DRIVER.
> If set:
> 	- read features, config
> If not set:
> 	- read features, config
> 	- reset
> 
This is what I explained.
It is more messy if you equate to GET command has mess.
> I am not saying it is elegant but then all of vdpa pile of hacks is not elegant.
> 
I don't want to comment for vdpa. But it is not part of the spec...

> And I am all for building something better but we didn't build it yet.

The proposal for 1.4 is literally very simple as below.
1. All existing fields of cfg space stays in cfg space
2. Any new capabilities to be queried, query using a vq (aq, cfgvq, whatevervq).
3. Optionally existing fields can be queries over vq of #2

Once this arrive, no need for new GET commands.
Till that time, don't keep infinitely grow the cfg space.
Any next addition to cfg space, should work on defining the cfgvq.