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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Jun 22, 2023 at 05:51:41PM +0000, Parav Pandit wrote:
> 
> > From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> > Behalf Of Michael S. Tsirkin
> > Sent: Thursday, June 22, 2023 1:38 PM
> > 
> > On Thu, Jun 22, 2023 at 05:15:50PM +0000, Parav Pandit wrote:
> > >
> > >
> > > > 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.
> > 
> > If you provision VFs differently. I got it.
> > 
> > > > - 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.
> > 
> > At least it works.
> >
> And new GET command also works when CVQ is trapped.

Not just trapped. You need to issue these commands.
That will require
- driving cvq at guest boot, sending commands, then reset
- poking at guest memory to change CVQ contents on
  the fly to mask commands.

How bad or hard is that? I'll need to ponder this a bit.


> And also works when AQ is querying capabilities of a member device using WIP cmd.

yes that's the way forward in 1.4.

> > > > 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...
> > 
> > Neither is QEMU.  It's one of spec implementations. Yes, we care about not
> > adding blockers for features that, superficially, might make sense for them.
> > 
> > > > 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.
> > 
> > Simple, but short sighted. I know you guys don't support your hardware for 10-
> > 20 years but for software people do.
> > And so "All existing fields of cfg space stays in cfg space" is a bad idea simply
> > because this does not allow removing things from config space not in 10 not in
> > 20 years not ever.
> >
> #1 is for backward compat for existing drivers.
>  You missed about #3. Existing cfg space fields can be queries using the cfgvq too.

Then #1 does not matter. We can give devices choice.

> > 
> > Instead we need to allow two ways to access config space.  Teach drivers about
> > both, actually mandate supporting both.  And then devices will make their own
> > cost/benefit decision about which features they want to support in MMIO.
> 
> If both method is mandated, I don't see benefit at all of two methods.

Mandated for driver.
Benefit is for devices, they will have the choice which drivers to
support. In 10-20 years all drivers support cfg command and then
people can start shipping devices without MMIO access to any
registers.

> VQ is generic part of the spec for slow and fast operation, so it is not at all a cost for config reading.

This will depend. E.g. if there's a single command to get all of config
in one go, then it actually can be a speedup, reducing the # of VM
exits.

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org