Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

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

On Tue, May 23, 2023 at 09:32:41PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, May 23, 2023 2:17 PM
> > 
> > On Mon, May 15, 2023 at 02:30:55PM +0000, Parav Pandit wrote:
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Monday, May 15, 2023 6:09 AM
> > > > To be more specific, device config often has the same layout under
> > > > legacy and modern. Thus if getting an offset within device config,
> > > > same decoding logic should be reusable between legacy and modern.
> > > Modern device registers are directly accessible from the guest driver without
> > mediation for VF,SF,SIOV.
> > > Hence, there is no need to have commands for modern register access over
> > some VQ.
> > 
> > Yes, there's need, and some of it you were pushing yourself.
> Yes, there is need without mediation of AQ.
> It was discussed in depth cfgq idea with trade off.
> 
> > AQ will allow reduced memory with SRIOV, and support for SIOV.
> Already discussed, v0 and v1, mediation via AQ is not the way for SRIOV.
> SIOV starting with single goal of only backward compatilbity hence, AQ is also doesn't look future forward.
> 
> And your summary email, we parked it aside for now.

I am frankly lost at this point, this thread is too big.

So where do you want to go for this project?  I would like something
specific, email threads are growing too big.
I think the reason is that there is actually a host of small
related subprojects. So when you propose just this small
feature, everyone jumps in with their own pet project
proposing addressing that too.

For example:
- SIOV guys were adding transport over VQ. It would seem that
  can include support for legacy.
- For migration we need ability to report member events to owner.
  It would seem that can be used to support INT#x.
- Ability to stick capabilities in extended config space
  is a good idea, for a variety of reasons.

and so on.  Understandably frustrating, and it is easy to go overboard
with generality.

If you feel your path for progress is clear, that's good.
if not, here are ideas for getting this unstuck:
- start a TODO.md file with a list of things we need to address,
  and for each one a list of options
- everyone will add to this file then we get a higher level
  picture and can discuss "this will be addressed by A, that by B"
- have a chat at the upstream developers meeting (May 31)
  so far it's about vdpa blk
- anyone coming to the kvm forum to have a chat there?

Hope this helps.
-- 
MST